UNIFIED CONCURRENT CHANGES TO DATA, SCHEMA, AND APPLICATION

• US 20110307524A1
• Filed: 06/11/2010
• Published: 12/15/2011
• Est. Priority Date: 06/11/2010
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Aitken, William Emeric, Avital, Noaa, Millet, Stephen J., Olenick, Brad, Kent, Simon David, Ahmed, Haroon, Bradley, Quetzal, Lovering, Bradford, Rezaei, Pedram Faghihi
• Granted Patent: US 8,768,902 B2
• Time in Patent Office: Days
• US Class Current: 707/803
• CPC Class Codes: G06F 16/00 Information retrieval; Database structures therefor; File system structures therefor
• CPC Class Codes: G06F 16/217 Database tuning G06F16/2282 takes precedence; database performance monitoring G06F11/3409
• CPC Class Codes: G06F 16/24535 of sub-queries or views
• CPC Class Codes: G06F 17/00 Digital computing or data processing equipment or methods, specially adapted for specific functions information retrieval, database structures or file system structures therefor G06F16/00

Abstract

Changes are managed in a multi-user database application environment. Proposed changes are collected, including changes to data, schema, and/or application descriptions. A user may specify foreign key relationships between items belonging to one or more of these categories. A view is produced showing the impact proposed changes would have on the environment if successfully committed. The user'"'"'s proposed changes are ordered according to their dependencies, and submitted for committal together in a single transaction, subject to optimistic concurrency and consistency checks. For example, a proposed change to a data value may be inconsistent with a change which removed a data element containing the data value. The commitment operation may return identifiers and other return values, in addition to indicating whether the commitment was successful.

Claims

1. A computer-readable non-transitory storage medium configured with data and with instructions that when executed by at least one processor causes the processor(s) to perform a process for managing changes in a multi-user database application environment, the process comprising the steps of:

collecting proposed changes to the multi-user database application environment prior to committing any of those changes;

identifying for a particular proposed change Y at least one precondition PreY presumed by Y and at least one postcondition PostY to be caused by committing Y;

identifying for a particular proposed change X at least one precondition PreX presumed by X and at least one postcondition PostX to be caused by committing X;

analyzing a dependency of change X and change Y by doing at least one of the following;

determining that PostY renders PreX unavailable,

determining that PostX allows PreY;

and then

ordering the proposed changes to form an ordered change list with change X preceding change Y in order of commitment in the list.

2. The configured medium of claim 1, wherein the ordering step performs at least one of the following:

places in the ordered change list a proposed schema change that would create a database element prior to a proposed data change that would write a value in that database element;

places in the ordered change list a proposed change that would reference a database element value prior to a proposed change that would remove that database element.

3. The configured medium of claim 1, wherein the process further comprises committing both change X and change Y in a single transaction.

4. The configured medium of claim 1, wherein the process further comprises:

obtaining exclusive access to a portion of the multi-user database application environment, the portion having a current state when the exclusive access is obtained; and

assessing for each proposed change whether all preconditions for that proposed change either exist in the current state or will be caused by proposed change(s) which precede that proposed change in the ordered change list.

5. The configured medium of claim 4, wherein the assessing step locates a proposed change having a precondition which does not exist in the current state and will not be caused by proposed change(s) which precede that proposed change in the ordered change list, and the process further comprises raising an error and preventing the proposed change from being committed.

6. The configured medium of claim 1, wherein the collecting step collects proposed changes in at least two of the following change categories:

data changes, schema changes, application changes.

7. The configured medium of claim 1, wherein the process further comprises:

ordering at least three proposed changes in order of commitment based on at least two analyzed dependencies, the proposed changes being in at least two of the following change categories;

data changes, schema changes, application changes;

verifying that precondition(s) of each proposed change will be satisfied at a commitment time of the proposed change; and

committing the proposed changes in order of commitment in a single transaction during which any change that would conflict with the proposed changes is barred.

8. The configured medium of claim 7, wherein the collecting step collects, and the committing step commits, at least one proposed change in at each of the following change categories:

data changes, schema changes, application changes; and

wherein the process further comprises getting at least one return value from the committing step.

9. A process for making changes in a multi-user database application environment, the process comprising the steps of a particular user of the environment:

observing values of the multi-user database application environment and submitting to an editor multiple proposed changes to at least some observed values of the multi-user database application environment, the proposed changes being in at least two of the following change categories;

data changes, schema changes, application changes; and

commanding the editor to commit all of the proposed changes together, as opposed to commanding the editor to commit one of the changes, receiving a response to that command, then commanding the editor to commit another of the changes, receiving a response to that command, and continuing to commit the changes one by one.

10. The process of claim 9, wherein the commanding step commands the editor to commit at least one proposed change in each of the following change categories:

data changes, schema changes, application changes.

11. The process of claim 9, wherein the process further comprises receiving a response to the commanding step which indicates that a proposed change is inconsistent with another change made after the observing and submitting steps and before the commanding step.

12. The process of claim 11, wherein the receiving step comprises at least one of the following:

receiving a response to the commanding step which indicates that a proposed change to change a data value is inconsistent with a change which (a) removed a data element containing the data value and (b) was made after the observing and submitting steps and before the commanding step;

receiving a response to the commanding step which indicates that a proposed change to change a data value is inconsistent with a change which (a) removed a database element containing the data value and (b) was made after the observing and submitting steps and before the commanding step;

receiving a response to the commanding step which indicates that a proposed change to change a data element type is inconsistent with a change which (a) renamed the data element and (b) was made after the observing and submitting steps and before the commanding step;

receiving a response to the commanding step which indicates that a proposed change to change a database element type is inconsistent with a change which (a) renamed the database element and (b) was made after the observing and submitting steps and before the commanding step;

receiving a response to the commanding step which indicates that a proposed change to change an application display rule for a data element is inconsistent with a change which (a) removed a database element and (b) was made after the observing and submitting steps and before the commanding step;

receiving a response to the commanding step which indicates that a proposed change to change an application display rule for a data element is inconsistent with a change which (a) renamed a database element and (b) was made after the observing and submitting steps and before the commanding step.

13. The process of claim 9, further comprising receiving from the editor a response indicating that an uncommitted proposed change is inconsistent with a committed change submitted by another user of the environment.

14. The process of claim 9, further comprising specifying at least one relationship between items belonging to one or more of the following categories:

data values, schema values, application values; and

providing the relationship(s) during the submitting step.

15. A computer system comprising:

at least one logical processor;

a memory in operable communication with the logical processor(s), the memory located in at least one machine;

a diff manager residing in the memory and operable to produce diffgrams from user gestures;

a user-specific change buffer residing in the memory and operable to maintain a collection of diffgrams for a specific user and to produce for the specific user views of a multi-user database application environment which reflect the impact that zero or more diffgrams would have on the environment if committed; and

a query-update engine residing in the memory and operable to (a) access a shared multi-user store of values in each of the following categories;

data values, schema values, application values, (b) submit value changes in each of these categories to the shared multi-user store, and (c) detect results after an attempt to commit changes in these categories to the shared multi-user store.

16. The system of claim 15, wherein the system further comprises a value change residing in the memory, the value change including a SQL statement in a context provided by at least one of the following:

an optimistic concurrency check, a check for consistency with a previous state.

17. The system of claim 15, wherein the query-update engine is operable to order proposed value changes based on dependencies between proposed value changes, and the system further comprises a value change list residing in the memory and containing proposed value changes of each category listed in a commitment order suitable for commitment under a single transaction.

18. The system of claim 15, wherein the system is operable to track which values are queried by the user during a period of operation of a multi-user database application, and the query-update engine is operable to produce value changes which are conditional in that they request commitment only after verifying that the values queried by the user have not changed.

19. The system of claim 15, wherein the query-update engine is operable to produce, and wherein the system further comprises:

value changes for relational values of a database, and value changes for graph objects of an application description.

20. The system of claim 15, wherein the system further comprises:

a single transaction containing a value change for a value of a database, a value change for a value of a database schema of the database, and a value change for an application description of an application for accessing the database, each of these value changes having the same user as an author.