Salesforce, Inc.

Salesforce Com, Inc.

Douglas Doole

Simon Y Wong

Abhijith Anilkumar

Rui Zhang

Rama Krishna Korlapati

Punit B Shah

Serge Philippe Rielau

Randy Philip Spalten

Techniques are disclosed relating to implementing a statement-level INSTEAD OF trigger. In one embodiment a computer system stores trigger information associated with a statement-level database trigger executable to initiate execution of at least one trigger instruction for a database instead of performing a particular database operation, on a database view, specified by a database operation statement. The computer system receives a first database operation statement specifying performance of the particular database operation on the database view and identifies a set of target rows, within the database view, targeted by the first database operation statement. In addition, the computer system generates a reference table associated with the database view, where the reference table includes rows corresponding to the target rows. The computer system executes the statement-level database trigger instead of executing the database operation statement, where executing the statement-level database trigger includes accessing the reference table.

Statement-level instead-of database triggers

Techniques are disclosed relating to implementing database trigger firing criteria to reduce unnecessary trigger firings. In one embodiment a computer system stores trigger information relating to initiating execution of at least one trigger instruction for a database, in connection with a particular database operation specified by a database operation statement. The trigger information includes a set of one or more database field identifiers for a set of one or more fields in the database. The computer system receives a first database operation statement and makes a determination that at least one field within the set of fields is not specified by the first database operation statement. Based at least in part on the determination, the computer system initiates execution of the at least one trigger instruction.

Operation statement analysis for database trigger firing

Techniques are disclosed relating to constructing a delta transition table for a database trigger. A computer system may store trigger information identifying a database trigger having a set of routines to be executed after an update operation has been performed on the database table. The computer system may perform a particular update operation that includes updating one or more rows of the database table. As part of performing the particular update operation, the computer system may construct a delta transition table that includes an original version of the one or more rows prior to the particular update operation and an updated version of the one or more rows resulting from the particular update operation. Subsequent to performing the particular update operation, the computer system may make the delta transition table available to the database trigger to facilitate an execution of the set of routines.

Delta transition table for database triggers

Techniques are disclosed relating to managing data objects. A computer system may access a first application comprising a set of functions and may execute a second application to facilitate execution of the first application. The first application may be written in a different programming language than the second application. The second application may manage, on behalf of the first application, memory resources of data objects that are defined within ones of the set of functions of the first application. The second application may establish, for the data objects, ownership information that indicates which ones of the functions are utilizing the data objects. The ownership information may be usable to determine, upon completion of a function of the set of functions, whether a given one of the data objects can be deallocated based on whether the given data object is being utilized by another function.

Lifecycle tracking of data objects

Caching runtime plan data that is determined not to change for different invocations of a query plan. In some embodiments, a computing system accesses information that specifies a query plan generated for a first database query and generates a first runtime plan for the first database query based on the query plan. In some embodiments, the system caches information generated for the first runtime plan that is determined not to change for different invocations of the query plan. For example, transformation code may include separate functions for mutable and immutable state. In some embodiments, the system retrieves and uses the cached information to generate a second runtime plan for a second database query. Disclosed techniques may improve performance of query plan transformations that hit in the runtime plan cache.

Growing community of inventors

Livermore, CA, United States of America

Douglas Doole