Methods and systems for recursive saving of hierarchical objects to a database

• US 8,918,361 B2
• Filed: 09/25/2013
• Issued: 12/23/2014
• Est. Priority Date: 10/04/2006
• Status: Active Grant

• Current Assignee: Salesforce.com, Inc.
• Original Assignee: Salesforce.com, Inc.
• Inventors: Wong, Simon Y., Macklem, Walter, Hofhansl, Lars, Rajaram, Varadarajan, Bezar, Eric
• Primary Examiner(s): Bhatia, Ajay
• Assistant Examiner(s): Le, Jessica N
• Application Number:
  US14/036,457
• Publication Number:
  US 20140025642A1
• Time in Patent Office: 454 Days
• US Class Current: 707/609
• CPC Class Codes: G06F 11/1402 Saving, restoring, recovering or retrying
• CPC Class Codes: G06F 16/2379 Updates performed during online database operations; commit processing

Abstract

Methods and systems include embodiments that recursively save parent, grandparent, and other records in a database that depend from a record. User-provided code within a save event or trigger can thus call further save methods without corrupting the database. Junction objects, objects that reflect records with two or more parents, can also be recursively saved.

Claims

1. A method at a database system having at least a memory and a processor therein, wherein the method comprises:

processing a set of records to be committed to the database system;

detecting a fault with a record within the set of records while processing the set of records to be committed to the database system;

performing fault recovery for the record having the fault, including at least;

(i) determining the record having the fault is a parent record which depends from a field value of a child record,

(ii) faulting the child record,

(iii) identifying resource limitations counted against governor limits used up by processing the set of records including the record having the fault and the faulted child record,

(iv) rolling back the identified resource limitations associated with the record having the fault and the faulted child record, and

(v) removing the record having the fault and the faulted child record from the set of records to be committed to the database system resulting in subset of the set records to be committed to the database system; and

committing the resulting subset of the set records to be committed to the database system.

2. The method of claim 1, further comprising:

recursively removing any faulting records from the set records to be committed to the database system, including removing the record having the fault and the child record having the fault applied thereto, from the set of records to be committed to the database system until a resulting subset of the set records to be committed to the database system is processed without faulting; and

wherein committing the resulting subset of the set records comprises committing the resulting subset having any faulting records removed therefrom.

3. The method of claim 1, wherein determining the record having the fault is a parent record which depends from a field value of a child record, comprises:

encountering the fault while recursively saving the record as a parent of the child record, and placing the fault on the child record originally causing the parent to be recursively saved.

4. The method of claim 1:

wherein the parent record depends from the field value of the child record and depends further from a second child record; and

wherein performing the fault recovery further includes faulting the second child record and removing the second child record from the set records to be committed to the database system.

5. The method of claim 1:

wherein the child record to the parent record constitutes a relationship selected from at least one of the following;

an object-parent relationship;

an object-parent-grandparent relationship;

an object-parent-grandparent-great-grandparent relationship; and

an object-parent-grandparent-greatgreatgrandparent relationship.

6. The method of claim 1, wherein determining the record having the fault is a parent record which depends from a field value of a child record further includes:

recursively determining that a grandparent record of the child record has a field that depends from a field value of the child record through the parent record.

7. The method of claim 6, wherein performing the fault recovery further includes locking records in the database system in the order of the grandparent record, the parent record, and then the child record.

8. The method of claim 1:

wherein processing the set of records to be committed to the database system includes executing user-supplied code for an object associated with the record having the fault; and

wherein performing the fault recovery further includes flushing the object associated with the record having the fault and rolling back any resource limitations associated with the executing user-supplied code for the object associated with the record having the fault.

9. The method of claim 8:

wherein detecting the fault includes validating the object using validation rules.

10. The method of claim 1, wherein processing the set of records to be committed to the database system includes updating the record determined to have the fault, wherein the updating for the record determined to have the fault includes at least one of:

processing for recursively deleting a record that is part of a hierarchy in a database system object and having a relationship to the record determined to have the fault;

processing for deleting the record having the fault from the database system;

processing for loading a parent object associated with the record having the fault into a second object;

processing for loading the parent object associated with the record having the fault into the second object based on the processing for deleting the record having the fault from the database system; and

processing for recursively loading a grandparent object from one or more child, grandchild, or greatgrandchild objects.

11. The method of claim 1, further comprising:

receiving a value for the child record;

wherein determining the record having the fault is a parent record which depends from a field value of a child record comprises determining the parent record is dependent on the received value for the child record;

recursively determining that a grandparent record to the child record has a field that is dependent on the received value for the child record;

loading the child record into an object;

updating the object with the received value for the child record; and

wherein performing the fault recovery further includes flushing the object having been updated with the received value for the child record.

12. The method of claim 1, further comprising:

receiving a value for the child record;

determining a second parent record to the child record depends from the field value of the child record, such that the child record has at least two parent records;

loading each of the two parent records to the child record into an object;

updating the object with the received value for the child record; and

wherein performing the fault recovery further includes flushing the object having been updated with the received value for the child record.

13. The method of claim 1, further comprising:

using recursion to recursively load, update, and flush objects corresponding to a great-grandparent record and other records related to the child record.

14. The method of claim 1, further comprising:

executing a workflow on an object corresponding to the record having the fault or the child record, or both, the workflow including a rule selected from the group consisting of an assignment rule, an auto-response rule, a workflow rule, and a case escalation rule.

15. The method of claim 1, wherein the database system operates as an on-demand database service on behalf of a plurality of tenants of a Multi-Tenant Database system implemented via the database system, the on-demand database service being accessible to the plurality of tenants via a global Internet network.

16. The method of claim 15, wherein the on-demand database service is accessible to the plurality of tenants via a web-based interface configured to:

execute software applications;

provide data, code, forms, and webpages to and from user systems communicably interfaced with the on-demand database service; and

store and retrieve data, objects, and Webpage content on behalf of the user systems communicably interfaced with the on-demand database service.

17. The method of claim 1:

wherein the database system stores data on behalf of a plurality of tenants of a Multi-Tenant Database system implemented via the database system; and

wherein the data for multiple tenants is stored within a same physical database object of the database system and is arranged such that data of one tenant is kept logically separate from data of other tenants, wherein the one tenant does not have access to the data of the other tenants unless the data of the other tenants is expressly shared.

18. The method of claim 1:

wherein the database system implements a Multi-Tenant Database system having therein elements of hardware and software that are shared by a plurality of customers of the Multi-Tenant Database system; and

wherein the Multi-Tenant Database system includes application servers which operate on behalf of the plurality of customers, each capable to simultaneously process requests on behalf of multiple of the plurality of customers.

19. Non-transitory computer readable storage media having instructions stored thereupon that, when executed by a processor of a database system, the instructions cause the database system to perform operations including:

processing a set of records to be committed to the database system;

detecting a fault with a record within the set of records while processing the set of records to be committed to the database system;

performing fault recovery for the record having the fault, including at least;

(i) determining the record having the fault is a parent record which depends from a field value of a child record,

(ii) faulting the child record,

(iii) identifying resource limitations counted against governor limits used up by processing the set of records including the record having the fault and the faulted child record,

(iv) rolling back the identified resource limitations associated with the record having the fault and the faulted child record, and

(v) removing the record having the fault and the faulted child record from the set of records to be committed to the database system resulting in subset of the set records to be committed to the database system; and

committing the resulting subset of the set records to be committed to the database system.

20. The non-transitory computer readable storage media of claim 19, further comprising:

recursively removing any faulting records from the set records to be committed to the database system, including removing the record having the fault and the child record having the fault applied thereto, from the set of records to be committed to the database system until a resulting subset of the set records to be committed to the database system is processed without faulting; and

wherein committing the resulting subset of the set records comprises committing the resulting subset having any faulting records removed therefrom.

21. The non-transitory computer readable storage media of claim 19, wherein determining the record having the fault is a parent record which depends from a field value of a child record, comprises:

encountering the fault while recursively saving the record as a parent of the child record, and

placing the fault on the child record originally causing the parent to be recursively saved.

22. The non-transitory computer readable storage media of claim 19, further comprising:

receiving a value for the child record;

wherein determining the record having the fault is a parent record which depends from a field value of a child record comprises determining the parent record is dependent on the received value for the child record;

recursively determining that a grandparent record to the child record has a field that is dependent on the received value for the child record;

loading the child record into an object;

updating the object with the received value for the child record; and

wherein performing the fault recovery further includes flushing the object having been updated with the received value for the child record.

23. A database system, comprising:

a memory;

one or more processors;

a physical database object to store a plurality of records; and

one or more sequences of instructions that when executed cause the one or more processors to;

(i) process a set of records to be committed to the database system;

(ii) detect a fault with a record within the set of records while processing the set of records to be committed to the database system;

(iii) perform fault recovery for the record having the fault via (a) instructions to determine the record having the fault is a parent record which depends from a field value of a child record, (b) instructions to fault the child record, (c) instructions to identify resource limitations counted against governor limits used up by processing the set of records including the record having the fault and the faulted child record, (d) instructions to roll back the identified resource limitations associated with the record having the fault and the faulted child record, and (e) instructions to remote the record having the fault and the faulted child record from the set of records to be committed to the database system resulting in subset of the set records to be committed to the database system, and

(iv) commit the resulting subset of the set records to be committed to the database system.

24. The database system of claim 23:

wherein the database system is to operate as an on-demand database service on behalf of a plurality of tenants of a Multi-Tenant Database system implemented via the database system, the on-demand database service being accessible to the plurality of tenants via a global Internet network.

wherein the database system stores data on behalf of the plurality of tenants within the physical database object, the data arranged such that data of one tenant is kept logically separate from data of other tenants, wherein the one tenant does not have access to the data of the other tenants unless the data of the other tenants is expressly shared;

wherein the Multi-Tenant Database system includes elements of hardware and software that are shared by the plurality of tenants of the Multi-Tenant Database system; and

wherein the Multi-Tenant Database system includes application servers which operate on behalf of the plurality of tenants, each capable to simultaneously process requests on behalf of multiple of the plurality of tenants.