When I merge accounts, I want to trigger an outbound message. When I merge account, there is 1 record that is updated and and the other record that goes to recycle bin. I want to fetch Record Id of one that is merged with and the one that is updated. Is it possible with any conditions or do i need to code?
Yes you need to write a trigger for this although a rather simple one.
As stated in documentation merge doesn't trigger they own event instead delete and uppate events triggered.
From Documentation :
To determine which records were deleted as a result of a merge operation use the
MasterRecordId field in Trigger.old. When a record is deleted after losing a merge
operation, its MasterRecordId field is set to the ID of the winning record.
Link to full page
Related
I have a table COMPANY where companies are kept. I want to create a view of that table, let's name it COMPANY_CDC but with one caveat:
When an entry in the original table is deleted, I want to set a deleted flag on the view entry instead of deleting it.
EDIT Why soft deletes? The point is that im performing change data capture using JDBC, and JDBC is only able to capture soft deletes. Inserts / updates are no problem.
If this cannot be done by using a view, what would be an alternative solution?
You can insert deleted values in another table using trigger
, and with join of these two table you can create your view.
Problem statement:
To always approve record updates before the changes reflect in main record. Want to try solving this problem using SQL database.
Eg.
User: { "name" : "Ravi Kumar", "city" : "Bangalore" }
Say we want to update the city to "Delhi" but it has to undergo approval before it reflects in the main record.
Once approved. It should show:
User: { "name" : "Ravi Kumar", "city" : "Delhi" }
Required Features:
Changes must get approved before they reflect in the main record
audit trail of the record to be maintained
how to support table joins? what if record is fetched using joining multiple tables? Basically if db is normalised.
Possible Solutions:
Have a additional column "approved" in the table. All approved records will have status 1 and rest will be 0. To get the current record we have to get record with the most recent timestamp with approved=1.
Have 2 tables one which contains the main table and another for approvals. When someone approves then we make changes to the record in main table.
Questions:
How to incorporate joins when there is normalisation? Is it simple or complex when joins are must? Is it even possible?
In case of joins, can we still implement using ORMs like hibernate?
If there are multiple updates waiting for approval on the same record and each update modifies different set of fields. If all of the records are approved then the record in consideration might only have the last update changes(Assuming one of above solutions are used).
Eg. There is a record in the main table and no unapproved records for it. Now a user changes a property say "name" and submits for approval. Another user changes property "city" and submits for approval. Another user changes property "salary" and submits for approval. All unapproved records are approved. Now last update(which changed salary property), that change contains old name not the one which is in first update. How to get all the approved changes.
This can be achieved by storing only changed properties instead of the whole. But it comes with cost of more code changes.
How are these problems tackled in the industry?
Related questions:
What's the best way to store changes to database records that require approval before being visible?
Structure to handle changes to records that require approval
If you want to be very careful about approving changes and you expect so many changes that it is likely that more changes will be made to a record before prior changes can be approved, then your best approach would be to have a separate set of tables with one record for each proposed change.
These "pending change" records could (should) include extra information about the change transaction, such as who proposed it and when.
Your process for handling all of these changes, and especially conflicting or overlapping changes will depend on your business rules, which you haven't stated definitively. Options include:
Prevent a second change while one is pending
Last change approved wins
Changes must be approved in sequence, overlaying earlier pending changes on top of the official data so that there is a presumption that all earlier changes will be approved prior to applying later changes
Regarding normalized databases and joins, this presents no special problems in your case. You will join the tables containing official, approved data as you would in any case. If you want to join to an interim/pre-approved version of a record, you should create a view which reflects these changes overlapped over the official data and then join to that view.
My question is a bit of a logical one. I hope my title is not misleading.
I'm working on a mail application like website where users can send or receive documents.
Documents are kept in a daabase table which holds attributes like Sender, Receiver, DeleteDate, DeleteuserId etc.
Let's look at this scenario.
A sends Document1 to B.
Document1 is at A's outbox and B's Inbox
A wants to delete it from the outbox
At this moment my deletion mechanism kicks in and sets the deletedate and deleteuserId of Document1 to date and Id of A respectively.
Problem is, now the document is logically deleted ( deletedate and deleteuserID are not null anymore) so both A and B can't see it because listing stored procedures don't allow "deleted" items to the list.
What kind of a logic should be implemented in order to let B see it and A don't ?
Not the best. but if you update the sender_id in the document table, then it will lost the connection with the document table. But if there is a some logic then you will create some other errors.
I was trying to figure out how to update the index for the deleted records. I'm indexing from the database. I search for documents in the database, put them in an array and index them by creating a SolrInputDocument.
So, I couldn't figure out how to update the index for the deleted records (because they don't exist in the database now).
I'm using the php-solr-pecl extension.
You need to handle the deletion of the documents separately from Solr.
Solr won't handle it for you.
In case of Incremental, You need to maintain the Documents deleted from the Database and then fire a delete query for the same to clean up the index.
For this you have to maintain a timestamp and delete flag to identify the documents.
In case of the Full, you can just clean up the index and reindex all.
However, in case of failures you may loose all the data.
Solr DIH provides a bit of handling for the same
create a delete trigger on the database table which will insert the deleted record id in another table.(or have boolean field "deleted" and mark the record instead of actually deleting it, considering the trade-offs I would choose the trigger)
Once in a while do a batch delete on index based on the "deleted" table, also removing them from the table itself.
We faced the same issue and came up with batch deletion approach.
We created a program that will delete the document from SOLR based on the uniqueid, if the unique id is present in SOLR but not in database you can delete that document from SOLR.
(Get the uniqueid list from SOLR) minus (uniqueid list from database)
You can just use SQL minus to get the list of uniqueid belonging to the documents that needs to be deleted.
Else you can do everything in JAVA side. Get the list from database, get the list from solr.. Do a comparison between the 2 list and delete based on that..This would be lost faster for huge number of documents. You can use binary search method to do the comparison..
Something like
Collections.binarySearch(DatabaseUniqueidArray, "SOLRuniqueid");
I have 3 tables: Notifications, NewItemNotifications and Items.
I've set an ON DELETE rule on the NewItemNotifications and Items table which deletes the NewItemNotification row when I delete some item.
The problem is that the parent row in the Notifications table is still exists, how can I handle this?
NewItemNotification is dependent table - it can never trigger deletion of parent record through database constraint. The only way is to write a database trigger on NewItemNotification to perform delete in Notification table after the dependent record is deleted.
The problem is that such trigger can cause issue if EF will try to delete NewItemNotification because it doesn't know about trigger existence. It first deleted NewItemNotification record which trigger deletion of Notification item without EF to know it. EF will then try to delete Notification record again but the record was already deleted. I think it will result in concurrency exception.
The best option in this case is not using cascade delete and handle delete yourselves.