1

I'm working on the restoring records for multiple objects that are stored in my local backup in the form of a database table. There seems to be an issue how the restore works. The scenario is as follows: There are nSObjects that are stored as database tables for backup to be restored (Assuming data that is consistent during the point in time).

For every sObject,

  1. If the sObject can be undeleted and exists in Recycle bin, it can be undeleted.

  2. If the record does not exist in the Recycle bin, I have to find the parentID that exists and restore it first using Bulk API's insert (Please confirm me if this is the only way to restore).

There are a few doubts in the above approach.

  • For a record to be undeleted, I have to identify the parent record/object. How do I do that given n sObjects?
  • Is undeleting the best way to conserve API limits? The reason is, if I have found out the parent record, why can't I make the approach 2 as a default/generic solution for any restores?
  • Is it always true that any related queries in SQL can be developed as:

Parent records: SELECT COLS FROM PARENT

Child records: SELECT COLS FROM CHILD WHERE PARENT.ID IN (CHILD.PARENTID)

Thanks.

1 Answer 1

0

If the record does not exist in the Recycle bin, I have to find the parentID that exists and restore it first using Bulk API's insert (Please confirm me if this is the only way to restore).

You would definitely need to restore the parent before attempting to restore the child, particularly if M-D relationship exists.

Is undeleting the best way to conserve API limits? The reason is, if I have found out the parent record, why can't I make the approach 2 as a default/generic solution for any restores?

To me, using #2 as the default approach would seem to be the simplest and easiest solution to your problem. I don't know how many records you have, but if doing it in bulk, I doubt that API limits would justify the time and efforts to determine what's in the recycle bin and what isn't.

It seems to me, the most reasonable way to approach the records in the recycle bin that makes any sense (assuming you want to go to the trouble), would be to first run a batch job to attempt to restore those records. Afterward, you'd want to export a list of what you were able to restore so you wouldn't need to attempt to insert existing records that had already been recovered from the recycle bin since you wouldn't want to do an upsert in that situation. If you did an upsert, you may as well have uploaded it all to begin with.

Sorry, but I can't answer any SQL questions. Ask me a SOQL question and you'd have a much better chance of getting a correct answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .