Methods and systems for bulk row save logic in an object relational mapping layer and application framework

• US 8,930,322 B2
• Filed: 10/23/2013
• Issued: 01/06/2015
• Est. Priority Date: 10/04/2006
• Status: Active Grant

• Current Assignee: Salesforce.com, Inc.
• Original Assignee: Salesforce.com, Inc.
• Inventors: Weissman, Craig, Tamm, Steven, Fell, Simon, Wong, Simon, Fisher, Steve
• Primary Examiner(s): KINSAUL, DANIEL W
• Application Number:
  US14/061,647
• Publication Number:
  US 20140046915A1
• Time in Patent Office: 440 Days
• Field of Search: None
• US Class Current: 707/684
• CPC Class Codes: G06F 16/21 Design, administration or maintenance of databases
• CPC Class Codes: G06F 16/284 Relational databases

Abstract

In accordance with embodiments, there are provided mechanisms and methods for saving multiple rows together through an object relational mapping layer to a database. These mechanisms and methods for saving multiple rows together can enable embodiments to detect faults in the save operation(s) and recover. The ability of embodiments to detect faults in the save operation(s) and recover can enable embodiments to provide a robust forgiving published API that saves a set of rows together whenever possible.

Claims

1. A method performed in a host system having a database therein to store rows and a processor to execute operations, wherein the method comprises:

saving a plurality of rows in the database as a set of rows, wherein one or more of the plurality of rows is associated with at least one side effect that is triggered to execute prior to saving or after saving but prior to committing the one or more rows, and wherein the one or more side effects comprises at least one of a pre-operation trigger, a post-operation trigger, or a code snippet;

determining that one or more faults has occurred in saving the set of rows in the database;

rolling back the set of rows to a known start state;

rolling back any side effects that were permitted to execute;

rolling back any resource usage counted against governor limits by executing side effects;

forming a new set of rows at the known start state including any of the plurality of rows which are not associated with the one or more faults having occurred when saving the set of rows in the database by removing all rows associated with the one or more faults during the saving of the set of rows in the database;

saving the new set of rows in the database from the known start state without fault; and

updating resources used and checking against governor limits.

2. The method of claim 1, further comprising:

receiving the set of rows via an Application Programming Interface (API) of the host system, wherein the set of rows are to be saved together in the database.

3. The method of claim 2, wherein receiving the set of rows comprises receiving information via the API to save to the set of rows together as part of a Simple Object Access Protocol (SOAP) compatible transaction.

4. The method of claim 2, wherein the API implements an object relational mapping layer to the database.

5. The method of claim 1, wherein the host system provides access to data and applications hosted by the host system to a user interface device over a public Internet as part of an on-demand database service.

6. The method of claim 5, wherein the database comprises a multi-tenant database system having elements of hardware and software shared by multiple customers.

7. The method of claim 1, further comprising:

recording fault information for any row associated with a save operation that faults when saving the set of rows in the database; and

wherein forming the new set of rows by removing all rows associated with the one or more faults during the saving of the set of rows in the database is based on the fault information recorded.

8. The method of claim 1, further comprising:

repeating the determining that one or more faults has occurred and forming the new set of rows until a set of rows that can be saved from the known start state without fault is determined.

9. The method of claim 8, wherein repeating the determining and the forming further comprises repeating the rolling back the set of rows to a known start state, repeating the rolling back of any side effects that were permitted to execute, and repeating the rolling back any resource usage counted against governor limits by executing side effects.

10. The method of claim 1, wherein rolling back any side effects that were permitted to execute comprises rolling back code or operations whose execution was triggered by saving the set of rows and/or rolling back any operations performed on data within other rows in the database triggered by saving the set of rows.

11. The method of claim 1, wherein saving the new set of rows in the database from the known start state without fault comprises saving the new set of rows in the database without receiving a failure report or saving the new set of rows in the database and receiving good return codes corresponding to the saving of the new set of rows, or both.

12. The method of claim 1, wherein saving the plurality of rows in the database as the set of rows constitutes bulk queuing and bulk processing of the set of rows.

13. The method of claim 12, wherein the bulk processing of the set of rows comprises at least one of:

(i) processing and packaging of Application Programming Interface (API) messages;

(ii) mapping to internal object representation as a list of rows being operated upon;

(iii) INSERT routines to the database using PL/SQL (Procedural Language/Structured Query Language);

(iv) lookup routines in the database for de-duplicate matching when performing updates to the rows stored in the database;

(v) UPDATE routines to the database using PL/SQL for record changes to the rows stored in the database;

(vi) DELETE routines to the database using PL/SQL for the rows stored in the database;

(vii) MRU (most-recently used list) maintenance for the database;

(viii) row-level sharing maintenance for the rows stored in the database;

(ix) entity store count maintenance for the rows stored in the database;

(x) reloading data after an update in preparation for performing post-save logic as part of a workflow; and

(xi) workflow implementation for bulk queuing and processing of tasks including child row creation, email processing, and outbound Simple Object Access Protocol (SOAP) messages.

14. The method of claim 1, further comprising:

committing the new set of rows when no faults have occurred.

15. Non-transitory machine-readable storage media having instructions stored thereupon that, when executed by a processor of a host system, the instructions cause the host organization to perform operations including:

saving a plurality of rows in a database as a set of rows, wherein one or more of the plurality of rows is associated with at least one side effect that is triggered to execute prior to saving or after saving but prior to committing the one or more rows, and wherein the one or more side effects comprises at least one of a pre-operation trigger, a post-operation trigger, or a code snippet;

determining that one or more faults has occurred in saving the set of rows in the database;

rolling back the set of rows to a known start state;

rolling back any side effects that were permitted to execute;

rolling back any resource usage counted against governor limits by executing side effects;

forming a new set of rows at the known start state including any of the plurality of rows which are not associated with the one or more faults having occurred when saving the set of rows in the database by removing all rows associated with the one or more faults during the saving of the set of rows in the database;

saving the new set of rows in the database from the known start state without fault; and

updating resources used and checking against governor limits.

16. The non-transitory machine-readable storage media of claim 15:

wherein the host system provides access to data and applications hosted by the host system to a user interface device over a public Internet as part of an on-demand database service; and

wherein the database comprises a multi-tenant database system having elements of hardware and software shared by multiple customers.

17. The non-transitory machine-readable storage media of claim 15:

wherein saving the plurality of rows in the database as the set of rows constitutes bulk queuing and bulk processing of the set of rows; and

wherein the bulk processing of the set of rows comprises at least one of;

(i) processing and packaging of Application Programming Interface (API) messages;

(ii) mapping to internal object representation as a list of rows being operated upon;

(iii) INSERT routines to the database using PL/SQL (Procedural Language/Structured Query Language);

(iv) lookup routines in the database for de-duplicate matching when performing updates to the rows stored in the database;

(v) UPDATE routines to the database using PL/SQL for record changes to the rows stored in the database;

(vi) DELETE routines to the database using PL/SQL for the rows stored in the database;

(vii) MRU (most-recently used list) maintenance for the database;

(viii) row-level sharing maintenance for the rows stored in the database;

(ix) entity store count maintenance for the rows stored in the database;

(x) reloading data after an update in preparation for performing post-save logic as part of a workflow; and

(xi) workflow implementation for bulk queuing and processing of tasks including child row creation, email processing, and outbound Simple Object Access Protocol (SOAP) messages.

18. A host system comprising:

a processor to execute operations;

a database to store rows;

a network interface communicably connecting the host system with user interface devices via a network; and

one or more stored sequences of instructions which, when executed by the processor, cause the processor to perform operations comprising;

saving a plurality of rows in the database as a set of rows, wherein one or more of the plurality of rows is associated with at least one side effect that is triggered to execute prior to saving or after saving but prior to committing the one or more rows, and wherein the one or more side effects comprises at least one of a pre-operation trigger, a post-operation trigger, or a code snippet;

determining that one or more faults has occurred in saving the set of rows in the database;

rolling back the set of rows to a known start state;

rolling back any side effects that were permitted to execute;

rolling back any resource usage counted against governor limits by executing side effects;

forming a new set of rows at the known start state including any of the plurality of rows which are not associated with the one or more faults having occurred when saving the set of rows in the database by removing all rows associated with the one or more faults during the saving of the set of rows in the database;

saving the new set of rows in the database from the known start state without fault; and

updating resources used and checking against governor limits.

19. The host system of claim 18:

wherein the network constitutes a public Internet;

wherein the host system provides access to data and applications hosted by the host system to a user interface device over the public Internet as part of an on-demand database service; and

wherein the database comprises a multi-tenant database system having elements of hardware and software shared by multiple customers.

20. The host system of claim 18:

wherein saving the plurality of rows in the database as the set of rows constitutes bulk queuing and bulk processing of the set of rows; and

wherein the bulk processing of the set of rows comprises at least one of;

(i) processing and packaging of Application Programming Interface (API) messages;

(ii) mapping to internal object representation as a list of rows being operated upon;

(iii) INSERT routines to the database using PL/SQL (Procedural Language/Structured Query Language);

(iv) lookup routines in the database for de-duplicate matching when performing updates to the rows stored in the database;

(v) UPDATE routines to the database using PL/SQL for record changes to the rows stored in the database;

(vi) DELETE routines to the database using PL/SQL for the rows stored in the database;

(vii) MRU (most-recently used list) maintenance for the database;

(viii) row-level sharing maintenance for the rows stored in the database;

(ix) entity store count maintenance for the rows stored in the database;

(x) reloading data after an update in preparation for performing post-save logic as part of a workflow; and

(xi) workflow implementation for bulk queuing and processing of tasks including child row creation, email processing, and outbound Simple Object Access Protocol (SOAP) messages.