Database implementation for different application versions

Abstract

This article discloses a technology for processing database queries from multiple different application versions using a single database. A computer system executing a database management system (DBMS) can receive a database query from a specific version of an application having multiple versions. The database query can specify a specific version. The computer system can then identify a directory table, wherein the directory table includes a version information column that stores version access information. The computer system can determine version access information for the database query that indicates that one or more database objects corresponding to the database query can be accessed by the specific version of the application. Based on this determination, the computer system can access one or more database objects that are responsive to the database query and can be accessed by the specific version of the application, which can advantageously reduce or avoid duplication of data stored in the database.

Description

Background Art Technical Field

[0002] The disclosure relates generally to databases, and more particularly to implementing a single database for multiple application versions.

[0003] Description of Related Technology

[0004] As applications are updated, applications are often shut down while their corresponding databases are updated, for example, using data definition language (DDL) statements. For example, the schema of a database may be changed for an updated application. This often results in an application shutdown, which may hamper the performance of the application, thereby affecting the user experience. In addition, the owner or developer of the application may wish to maintain the previous version of the application along with the new updated version of the application. Such a multi-version implementation may introduce errors and / or delays during the implementation of the application by a database management system (DBMS) that handles the databases for multiple versions of the application. For example, the database index of a new application version may interfere with the implementation of a previous version of the application. Specifically, when an index corresponding to a previous version of the application is deleted in the new version, the DBMS needs to prevent the newly created index from interfering with the previous version. If this prevention is unsuccessful, this may cause delays in processing queries from the previous version of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram illustrating an example system configured to process database queries from different application versions according to some embodiments.

[0006] Figure 2 is a block diagram illustrating an example system directory for a database management system according to some embodiments.

[0007] Figure 3 is a block diagram illustrating example version and mode catalog tables according to some embodiments.

[0008] Figure 4 is a block diagram illustrating an example database including an employee table for a human resources (HR) application according to some embodiments.

[0009] Figures 5A-5D is a block diagram illustrating example changes to a column catalog table based on adding, deactivating, undeactivating, and deleting columns, respectively, for a database table, according to some embodiments.

[0010] Figure 6 is a block diagram illustrating an example database table catalog table during creation of a database table according to some embodiments.

[0011] Figure 7 is a block diagram illustrating example index catalog tables during creation of a database index according to some embodiments.

[0012] Figure 8 is a block diagram illustrating an example trigger catalog table during the addition of a database trigger according to some embodiments.

[0013] Fig. 9 is a block diagram illustrating an example procedure catalog table during an add database procedure according to some embodiments.

[0014] Fig.10 is a block diagram illustrating an example statistics catalog table during the addition of database statistics according to some embodiments.

[0015] Fig.11 is a block diagram illustrating an example database query according to some embodiments.

[0016] Fig.12 is a flow chart illustrating a method for processing database queries from multiple different application versions according to some embodiments.

[0017] Fig.13 is a block diagram illustrating an example computing device according to some embodiments.

[0018] The disclosure includes references to "one embodiment" or "an embodiment." The appearance of the phrase "in one embodiment" or "in an embodiment" does not necessarily refer to the same embodiment. The particular features, structures, or characteristics may be combined in any suitable manner consistent with the disclosure.

[0019] In the open text, different entities (which may be variously referred to as "units", "circuits", other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This formula - [entity] is configured to [perform one or more tasks] - is used herein to refer to a structure (i.e., a physical thing, such as an electronic circuit). More specifically, the formula is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure can be said to be "configured to" perform some tasks even if the structure is not currently being operated. "A computer system configured to receive a database query to a database" is intended to cover, for example, a computer system having a processor, a network interface, a memory with program instructions, etc. to perform the function during operation, even if the computer system in question is not currently being used (e.g., it is not connected to a power source). Therefore, an entity described or recorded as "configured to" perform some tasks refers to a physical thing, such as a device, a circuit, a memory storing program instructions executable to implement a task, etc. The phrase is not used herein to refer to an intangible thing.

[0020] The term "configured to" is not intended to mean "configurable to." For example, an unprogrammed FPGA would not be considered "configured to" perform some specific function, although it may be "configurable to" perform that function and may be "configured to" perform that function after being programmed.

[0021] As used herein, the terms "first," "second," and the like are used as labels for the nouns that precede them and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise specified. For example, in a computing system with multiple user accounts, the terms "first" and "second" user accounts may be used to refer to any user. In other words, for example, the "first" and "second" user accounts are not limited to the two user accounts that were initially created.

[0022] As used herein, the term "based on" is used to describe one or more factors that influence a determination. The term does not exclude the possibility that other factors may influence the determination. That is, a determination may be based only on specified factors or on specified factors as well as other unspecified factors. Consider the phrase "determining A based on B." The phrase specifies that B is a factor used to determine A or influence the determination of A. The phrase does not exclude that the determination of A may also be based on some other factor, such as C. The phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is therefore synonymous with the phrase "based at least in part on." DETAILED DESCRIPTION

[0023] In previous DBMS implementations, one approach for handling multiple application versions involves the new version of the application accessing a database management system (DBMS) to retrieve data for processing a user request. In this implementation, the DBMS can load a new database schema for the application into the database with a new schema name. In this example, the new database schema is simply a copy of the schema for the previous version of the application, but with changes corresponding to the execution of the new application. While this implementation works well for database objects that are easily copied (non-persistent objects such as triggers, indexes, statistics, etc.), it creates problems for persistent database objects (such as tables). For example, copying the entire contents of a database table multiple times for multiple different schemas is both expensive and inefficient.

[0024] The disclosure describes techniques for maintaining data for multiple different application versions in a single database. For example, the disclosed techniques handle queries from multiple application versions at a given time by implementing application versioning for different objects in the database within the database's system catalog. The system catalog maintains metadata describing database objects stored in the database. For example, an application may be associated with a particular schema in the database, and the schema includes a name and a version (so that the schema version corresponds to a given application version). The new versioning techniques involve adding additional columns to the database catalog tables to specify application versions associated with various database objects stored in the database. For example, these columns may specify a range of application versions using a start version and a stop version, or may specify a specific application version for an object in the database. These database objects may include tables, columns, triggers, indexes, statistics, procedures, views, and the like.

[0025] In the embodiments described herein, a new version of a client application may add a new column "Currency" to a "Sales" database table. In this example, the database management system adds a new row to a table in the system catalog, which includes metadata for the database column. This column catalog table specifies the name of the database table (Sales), the name of the added column (Currency), and the start and stop versions of the application associated with this added database column. The database management techniques described in the disclosure may advantageously allow multiple different versions of an application to be served simultaneously, while reducing or avoiding duplication of data stored in the database.

[0026] Example DBMS

[0027] Figure 1is a block diagram illustrating an example system configured to process database queries from different application versions. In the illustrated embodiment, system 100 includes a user computing system 110 and a DBMS 130 configured to communicate to process application requests.

[0028] In the illustrated embodiment, the user computing system 110 includes an application 120. The user computing system 110 may be an application server configured to facilitate the use of the application 120 by various different users. For example, in some embodiments, the system 110 may be a customer relationship management system that manages applications for various different customers. In some cases, different users (of the same or different customers) use the same application, but implement different versions of the application. For example, the system 110 may manage a human resources application for two different users, but each user implements a different version of the human resources application that accesses different data maintained by the DBMS. In some embodiments, a computing system other than the system 110 includes different versions of the application 120 and is configured to communicate with the DBMS 130 to process queries from these applications. In the illustrated embodiment, the user computing system 110 sends a query 102 to the DBMS 130 for the application 120. The query 102 specifies a specific application version.

[0029] In the illustrated embodiment, DBMS130 includes a system catalog 140 and a database 150. As used herein, the term "system catalog" is intended to be interpreted according to its well-understood meaning, which includes a portion of a database that stores metadata about the data stored in the database, such as the schema that defines database objects. For example, the system catalog may include various catalog tables and / or catalog views. These catalog tables may include metadata describing the data stored in various objects included in the database managed by the DBMS, such as databases: tables, columns, triggers, indexes, statistics, procedures, views, etc. These catalog tables can be used to determine the best method to evaluate, for example, a structured query language (SQL) query received from an application. The terms "catalog" and "catalog table" can be used interchangeably. In the public text, a catalog table specifies subsets of data sets stored in a database that are accessible by different application versions, including which database tables are visible to certain applications.

[0030] In the illustrated embodiment, system catalog 140 is a collection of tables that contain information about database objects stored in database 150. For example, system catalog 140 may include a list of schema identifiers corresponding to different versions of an application (or different applications). System catalog 140 includes various catalog tables 142A-N, each of which includes metadata for a different version. For example, in Figure 1 , directory tables 142A-N include metadata 144 for versions A and B of application 120. Figure 2 Discuss the sample directory table.

[0031] Similarly, in the illustrated embodiment, database 150 includes various database tables 152A-N, each of which includes data 154 for both version A and version B of application 120. In some embodiments, directory tables 142A-N and database tables 152A-N include metadata and data for different applications. For example, these tables may include metadata and data for both human resources applications and accounting applications. In addition, these tables may include metadata and data for different applications and different versions of the same application. For example, application version A may be an old version of a specific application, and may not see data in columns added to the database for application version B (a newer version of a specific application). However, in this example, version A may still be able to view data in columns that have been removed or disabled in version B. In other words, both application versions can see the same data rows with different sets of columns. DBMS130 may be any of a variety of database management systems (including PostgreSQL, MySQL, ORACLE, etc.).

[0032] The metadata stored in catalog table 142 may specify the location of database objects stored in database 150 and version access information for those objects. That is, the metadata included in catalog table 142 may indicate, for a particular application version, database objects stored in the database that are accessible by the application version and that can be used to respond to queries from the particular application version.

[0033] In the illustrated embodiment, DBMS 130 accesses system catalog 140 based on query 102 to determine database objects stored in database 150 that are accessible by the application version specified in the query. Based on this determination, DBMS 130 can use a query optimizer to generate a query execution plan for database 150. DBMS 130 then accesses database 150 based on the plan to retrieve data in response to query 102. DBMS 130 sends query results 106 to user computing system 110 for application 120. These results are associated with the application version specified in query 102.

[0034] As used herein, the term "application version" refers to a specific form of an application that is different from earlier or later forms of the application. For example, application versions can be assigned to new or updated versions of an application using a monotonically increasing numbering scheme that manages the accessibility of various database content to different application versions. As a specific example, a first version of an HR application can be assigned version 4.1.3, while a second version of the HR application can be assigned version 4.1.4. As used herein, the term "metadata" is intended to be interpreted according to its well-understood meaning, which includes data sets that describe other data. For example, metadata can be included in a catalog table of a system catalog. Specifically, the metadata can specify an application version associated with a particular schema in a database. Figure 3 and 5A -10 Detailed discussion of sample metadata stored in system catalogs.

[0035] Example System Catalog

[0036] Figure 2 2 is a block diagram illustrating an example system catalog 140 of DBMS 130. In the illustrated embodiment, system catalog 140 includes the following catalog tables: version catalog table 210, schema catalog table 220, column catalog table 230, database table catalog table 240, index catalog table 250, trigger catalog table 260, procedure catalog table 270, and statistics catalog table 280. Note that any of a variety of other catalog tables for various other types of database objects may be included in system catalog 140 and managed by DBMS 130.

[0037] Figure 2 The directory tables shown in 230 may include entries (rows) for different objects in database 150. For example, column directory table 230 may include entries for various database columns, where the entries include fields with values ​​specifying the position of the column in database 150 and version access information. Figure 3 and 5A -10 discusses the different directory tables in more detail.

[0038] Table of example versions and pattern catalogs

[0039] Figure 3 2 is a block diagram illustrating example version and mode catalog tables. In the illustrated embodiment, system catalog 140 includes version catalog table 210 and mode catalog table 220.

[0040] Version catalog table 210 is a table that allows DBMS130 to find a specific version ID for a name associated with a specific version of an application and determine the status of the specific version (whether the application version is enabled or disabled, etc.). In the illustrated embodiment, version catalog table 210 includes three columns: version identifier (ID) 312, version name 314, and version status 316. In the table, three different entries (rows) are shown for three different versions of the application. Specifically, the first entry in version catalog table 210 includes mode information for application version 204.7.2, including version name, summer 2019, and version status indicating that the application version has been disabled. Similarly, application version 204.7.3 is named autumn 2019 and is enabled, while application version 204.7.4 is named spring 2020 and is currently under construction. Version catalog table 210 can include any number of entries, where the application is in various versions and various states, with unique version IDs and application names.

[0041] In the illustrated embodiment, the system catalog 140 includes a schema catalog table 220 that can be used to look up which specific schema (based on its schema ID) applies to a given schema name and a given application version. Specifically, the schema catalog table 220 includes three columns, designated as: schema ID 322, schema name 324, and version ID 312. The version ID 312 column of the schema catalog table 220 is the same as the version ID column of the version catalog table 210. The first schema (represented by schema ID 1) is named HR (e.g., Figure 3 ) and corresponds to version ID 204.7.2. This pattern continues for other schema IDs, with each new schema ID corresponding to a new version ID. However, schema ID 4 corresponds to an unversioned schema. An unversioned schema is a schema that is visible to existing versions of an application. In some cases, certain database objects (such as views or functions) can be placed in an unversioned schema because these database objects are expected to remain unchanged across application versions. For example, other database objects such as database tables can be placed in an unversioned schema so that the data stored in these objects can be available in various versions of the application. In some cases, a version ID of 0 indicates that the database object has been deactivated or deleted. Figure 5D An example is shown where the database column is deleted and the corresponding version ID of the start version column is 0. Schemas can be defined on a per-application basis (using specific names), but a given schema can be shared by multiple instances of the same application. Thus, the name "HR" can be the name of a schema for a specific application, and may also be referred to as "HR" in some embodiments.

[0042] although Figure 3 An entry for a schema named HR is shown, but the table may include entries for schemas with different names, such as Accounting, Recruiting, Process, etc. A particular application may use multiple different schemas. As a specific example, an application associated with version 204.7.2 and generated in the summer of 2019 is a human resources application that may use the schemas "HR" and "Recruiting".

[0043] Sample Database

[0044] Figure 4 is a block diagram illustrating an example database 150 including an employee table 410 for a human resources (HR) application. In the illustrated embodiment, the database 150 includes the hr.employee table 410, hr.emp_name_index 420, hr.emp_name_comp index 430, and hr.totalcomp procedure 440. Figure 4 The table shown in describes, for example, a superset of data that may be stored for multiple versions of the same application (or different applications) within DBMS 130. As will be discussed in more detail below with reference to subsequent figures, based on the version information defined in metadata 144 of system catalog 140, a given application may be allowed to query only a subset of the information stored in database 150.

[0045] In the illustrated embodiment, the hr.employee table 410 includes four different columns: employee ID 412, employee name 414, salary 416, and bonus 418. The hr.employee table 410 includes three entries, one for each of Michael Smith, John Doe, and Jane Doe. For example, Jane Doe is associated with employee ID 12347, has a salary of $120,000, and has a bonus of $6,000. In some embodiments, the database 150 includes a second table named customers. The customers table, along with the hr.employee table 410, may include different versions for the HR application. In some cases, the employee and customer tables include data for different applications (e.g., a human resources application and an accounting application). As will be described below with reference to Figures 5A-5D and Fig.11 As discussed, some application versions may not be able to access some columns included in the hr.employee table 410 .

[0046] hr.emp_name_index 420 includes the employee name 414 and salary 416 columns of the employee table 410, while the hr.emp_name_comp index 430 includes the employee name 414 column of the hr.employee table 410 and a total 432 column including the total value of the salary and bonus for each employee. For example, the value stored in the total column 432 can be determined by executing the hr.totalcomp procedure 440, which is a function that calculates the sum of two different parameters, salary and bonus. The hr.totalcomp procedure 440 receives an employee ID or an employee name as input and outputs the total compensation for the employee.

[0047] In some embodiments, database 150 includes additional database objects. For example, database 150 may include triggers and statistics as well as any other various database objects. In particular, database 150 may include statistics for salary 416 column of hr.employee table 410 that tracks the average salary of all employees listed in table 410. An application version may access information stored in database 150 via a query that specifies a corresponding application version, as described below with reference to Fig.11 For example, these database indexes may not be visible to a particular application version, but may be visible to other versions of the particular application.

[0048] Sample Catalog Table

[0049] Figures 5A-5D is a block diagram illustrating example changes to the column catalog table 230 based on adding, deactivating, undeactivating, and deleting columns of a database table, respectively. Figures 5A-5D In the example of FIG. 1 , application 120 sends database commands to DBMS 130 specifying updates based on the new version of the application. For example, these database commands may include data definition language (DDL) operations. In many cases, the new version of application 120 is sending DDL operations to DBMS 130 based on new information used by the application during operation.

[0050] exist Figure 5A, application 120 generates a database command 502 for database 150 and transmits the command to DBMS 130. The database command sent from application 120 to DBMS 130 can be a SQL, Postgres, MySQL, etc. command. Database command 502 includes two different operations. The first operation specifies that the current application version is 204.7.3. For example, application version 204.7.3 is the application version associated with the second operation. The second operation specifies to update hr.employee table 410 by adding a bonus 418 column (for example, the employee table does not yet include a bonus column 418). Based on the database command, DBMS 130 updates the metadata stored in system catalog 140 and the database objects stored in database 150 (not shown).

[0051] Figure 5A The DBMS 130 in the example includes a column catalog table 230 that stores metadata of database columns included in the database 150. For example, returning to Figure 3 , the database 150 includes an hr.employee table 410 having four database columns: employee ID 412, employee name 414, salary 416, and bonus 418. Return to Figure 5A , the column catalog table 230 includes five different columns: table ID 532, column number 534, column name 536, start version 590, and stop version 592. These five columns specify metadata of database columns included in the database 150. For example, the column catalog table 230 includes an entry specifying that a database column named salary 416 is included in table ID 6 (hr.employee table 410), is associated with schema ID 3, and is applicable to applications starting with version 204.7.2. As a specific example, in the PostgreSQL context, the column catalog table 230 is referred to as pg-attribute, where the term "attribute" is equivalent to column and is used for historical reasons.

[0052] In the illustrated embodiment, the start version 590 and stop version 592 columns included in the column catalog table 230 specify for different database columns the application versions that can access the column (start version 590) and the application versions that can no longer access these database columns (stop version 592). For example, the start and stop version columns included in the column catalog table 230 specify a range of application versions that are aware of the data stored in a particular database column. For example, if application version 204.7.2 attempts to access all columns of the hr.employee table 410, the bonus column data will not appear in the column data returned to the application. In addition, if this application version attempts to directly reference the bonus column in a query, the query response message will specify "column bonus not found".

[0053] The implementation of start and stop version columns can advantageously prevent older application versions from being slowed down due to those versions' reliance on indexes that have been deleted in newer application versions. This can also prevent newer application versions from violating service level agreements (SLAs) (e.g., queries from customer applications need to be satisfied within a threshold time). In addition, the use of start and stop version columns can allow information about multiple application versions to be stored in a single table rather than multiple tables, each of which is dedicated to a specific version. This in turn can reduce or eliminate the need for the DBMS to keep data synchronized between multiple tables. For example, versioning of column data can reduce or eliminate the risk of semantically breaking an application due to a single copy of a database table including columns visible to all application versions. In this example case, the query "SELECT * FROM employee table" may return additional columns. The disclosed versioning techniques can also reduce or prevent data stored in columns that are intended to be deactivated from newer versions of database tables from being accidentally accessed by newer application versions without the application developer being aware of the data stored in the deactivated object.

[0054] DBMS 130 receives database command 502 from application 120 and performs a DDL operation that can be performed to change the column ( Figure 4 418 in the employee table) is added to the database 150. In addition to and concurrently with the DDL operation of the database 150, the DBMS 130 updates the column catalog table 230 by performing a column add operation 512. For example, the column add 504 operation may be performed to add an entry to the column catalog table 230. Specifically, the DBMS 130 adds a row to the column catalog table 230 whose value specifies that the new column is named "Bonus" and is included in the employee table corresponding to table ID 6 (the new row is shown in bold in the figure). In the depicted example, application version 204.7.3 or later can access the Bonus database column, but application version 204.7.2 or older will not be able to access it.

[0055] In some embodiments, the system catalog 140 includes primary keys and unique constraints for different catalog tables. A primary key may include a set of columns with unique values ​​in a table that are used to identify a row when referenced from another table. For example, a column catalog table 230 may include a primary key consisting of a table ID 532 and a column number 534 column. The primary key may be used to identify a specific row within the column catalog table 230. Similarly, a unique constraint may include a set of columns with unique values. For example, a column catalog table 230 may include a unique constraint consisting of a table ID 532 and a column name 536 column.

[0056] In some embodiments, the database command includes multiple updates for a given application version. For example, database command 502 may include multiple different operations (such as the second operation "change table") indicating the differences between the database objects accessible by the previous version and the database objects accessible by version 204.7.3.

[0057] exist Figure 5B , the application 120 sends a database command 504 to the DBMS 130 that specifies the application version 204.7.4 and includes an operation for deactivating a database column. Based on the database command 504, the DBMS 130 performs a column deactivation operation 514 to change the column catalog table 230 by adding a stop version 592 (204.7.4) to the row of the table 230 that includes metadata for the bonus database column. In this example, the bonus column included in the employee database table can only be accessed by version 204.7.3 of the human resources application.

[0058] In some cases, during the development of application version 204.7.3 (e.g., before the disabled column is exposed via a new application version release), the bonus column may be disabled by mistake. This deactivation can be reversed in the same application version. To mitigate this error, application 120 can un-deactivate the bonus column. For example, in Figure 5C , the application 120 sends a database command 506 to the DBMS 130, specifying the application version 204.7.4. The database command 506 includes an operation for un-activating the bonus column in the database 150. Based on the command, the DBMS 130 performs a column un-activation operation 516 to update the column catalog table 230 to specify that the discontinued version 592 of the bonus database column is "0".

[0059] exist Figure 5D , the application 120 sends a database command 508 to the DBMS 130 that includes an operation that specifies the deletion of the bonus column in the database 150. Based on the database command 508, the DBMS 130 performs a column deletion operation 518 to update the column catalog table 230 so that its start version column 590 specifies version "0" for the bonus database column. In some cases, the application 120 is allowed to delete the column (or any other database object) only if the column is no longer available for use in other application versions. That is, the stop version 592 column of the bonus column must specify an application version that is earlier than or the same as the oldest version of the application. For example, a column can be deleted when it is deactivated in an application version that is older than the last supported version of the application.

[0060] Figure 6is a block diagram illustrating an example database table catalog table during the creation of a database table. In the illustrated embodiment, the database catalog table 240 includes the following columns including metadata specifying data stored in a table of the database 150: table ID 542, schema ID 322, table name 644, start version 590, and stop version 592. The database catalog table 240 includes metadata specifying whether information stored in a database table of the database 150 is visible to different application versions. For example, the first row of the database table catalog table 240 includes a table ID of 6, a schema ID of 4, named "employee", and accessible by applications starting with application version 204.7.1. Schema ID 4 refers to an unversioned schema, and therefore, the employee table (table ID 6) can be visible to multiple different application versions. In some cases, it may be desirable for database tables to be visible in various application versions, and therefore, these database tables may exist in an unversioned schema.

[0061] In the illustrated embodiment, the application 120 sends a database command 602 to the DBMS 130. The database command includes an operation for creating a table called "Customers" in the database 150. After the Customers table is generated in the database 150, the DBMS 130 performs a database table creation operation 612 to add an entry to the database table catalog table 240 in the system catalog 140. In the illustrated embodiment, the second row of the database table catalog table 240 specifies application version 204.7.1 as the starting version 590 of the Customers database table. In this example, applications associated with versions 204.7.1 and later can access both the Employees and Customers database tables.

[0062] Figure 7 is a block diagram illustrating an example index catalog table during creation of a database index. In the illustrated embodiment, the index catalog table 250 includes the following columns including metadata specifying the data in the index stored in the database 150: table ID 542, index name 764, start version 590, and stop version 592. The index name 764 column stores, for example, values ​​specifying the names of various different database indexes.

[0063] In the illustrated embodiment, DBMS 130 receives a database command 702 from application 120 specifying the creation of a new index in database 150. Based on the command, DBMS 130 generates a new index hr.emp_name_comp 430. After generating the new index, DBMS 130 performs an index creation operation 712 to add an entry to the index catalog table 250 of index 430, indicating that the index can be accessed by application version 204.7.3 (and later versions), and therefore the index cannot be used by application version 204.7.2 and earlier versions. However, DBMS 130 will maintain the indexes that exist in the database, even in the case where certain application versions (such as version 204.7.2 and earlier versions) cannot use (cannot utilize) these indexes.

[0064] Figure 8 is a block diagram illustrating an example trigger catalog table during the addition of a database trigger. In the illustrated embodiment, the trigger catalog table 260 includes the following columns with metadata specifying the triggers stored in the database 150: table ID 532, trigger ID 862, trigger name 864, start version 590, and stop version 592. Trigger ID 862 and trigger name 864 store values ​​specifying identifiers and names, respectively, for various database triggers, for example.

[0065] In the illustrated embodiment, DBMS 130 receives a database command 802 from application 120 specifying that a trigger be added to database 150. Based on the command, DBMS 130 generates a new trigger on the bonus column of the employee table in database 150. After adding the trigger to database 150, DBMS performs a trigger add operation 812 to add an entry to trigger catalog table 260 for a new "bonus trigger" for application version 204.7.3. In this example, the "bonus trigger" will only execute for applications associated with version 204.7.3 or higher.

[0066] Fig. 9 is a block diagram illustrating an example process catalog table during the addition of a database process. In the illustrated embodiment, process catalog table 270 includes the following columns with metadata specifying processes stored in database 150: process ID 972, schema ID 974, and process name 976. The process ID 972 and process name 976 columns, for example, store values ​​specifying identifiers and names of various database processes, respectively.

[0067] In the illustrated embodiment, DBMS 130 receives a database command 902 from application 120 specifying that a procedure be added to database 150. Based on the command, DBMS 130 adds a procedure to a particular schema in database 150 (corresponding to the procedure according to Figure 3 4) generates a new procedure called "Retire" for the application version 204.7.4 in the schema catalog table 220 of the schema ID 3. After the new procedure is added to the database 150, the DBMS 130 performs a procedure add operation 912 to add an entry to the procedure catalog table 270 for the new "Retire" procedure for schema ID 3. In this example, the procedure "Retire" is visible only to queries of the application associated with version 204.7.4.

[0068] Fig.10 is a block diagram illustrating an example statistics catalog table during the addition of database statistics. In the illustrated embodiment, the statistics catalog table 280 includes the following columns with metadata specifying statistics for different database tables stored in the database 150: table ID 532, width statistics 982, invalidation statistics 984, start version 590, and stop version 592. Width statistics 982 and invalidation statistics 984 are non-limiting examples of the types of statistics that may be generated for a given database table. Width statistics 982 may, for example, specify the average storage width (in bytes) of non-null entries in a given database table.

[0069] In the illustrated embodiment, database commands 1002 include an operation for loading statistics for the hr.employee database table 410 into the database 150. After performing this operation, DBMS 130 performs a statistics add operation 1012 to add an entry to the statistics catalog table 280 specifying the width and invalidation statistics for version 204.7.2 of the human resources application. In this example, the query optimizer of DBMS 130 will only use the invalidation statistics for queries from applications associated with version 204.7.2 or later.

[0070] Fig.11 1 is a block diagram illustrating an example database query 1102. In the illustrated embodiment, system 1100 includes application 120 and DBMS 130. Application 120 sends query 1102 to DBMS 130. Query 1102 specifies that application 120 is currently operating under version 204.7.2, and therefore, this query requests access to database objects that this version can access. In addition, query 1102 specifies that data generated by hr.totalcomp procedure 440 for an employee named "John Doe" is selected.

[0071] The following example description includes Figure 4 References to database objects shown in . Fig.11The application 120 shown in FIG. 1102 may be a human resources application that requests compensation information for a particular employee (John Doe). In response to query 1102, DBMS 130 accesses system catalog 140 to determine if procedure "totalcomp" belongs to schema ID 1. Based on determining that it does belong to schema 1, DBMS 130 verifies that: 1) schema ID 1 is a schema named "HR" and 2) schema ID 1 is a schema that matches application version 204.7.2. Based on this information, DBMS 130 accesses database 150 to obtain the results of calculating total compensation (salary + bonus) for John Doe.

[0072] Note that query 1102 can be satisfied by accessing hr.employee table 410 to obtain John Doe's salary and bonus information, accessing hr.totalcomp procedure 440 and then inserting these values ​​into procedure 440 or by accessing hr.emp_name_comp index 430 (if this index is accessible to application version 204.7.3 - in this example) and obtaining the sum 432 of John Doe's salary 416 and bonus 418 columns. If DBMS 130 uses the hr.emp_name_comp index to respond to query 1102, the system will first access index catalog table 250 to determine that the hr.emp_name_comp index is accessible starting with application version 204.7.3. In this example scenario, DBMS 130 then checks that the salary, bonus, and name columns of hr.employee table 410 are visible to version 204.7.3 of the application. The DBMS then determines that the emp_name and emp_name_comp indexes are visible to version 204.7.3 of the application. Based on this information, DBMS 130 will then access database index 430 to obtain the data requested by application 120. If the emp_name_comp index had been added in application version 204.7.4 instead of 204.7.3, DBMS 130 would have to forgo using that index. In the illustrated embodiment, after accessing database 150 to obtain John Doe's total compensation, DBMS 130 sends query results 1104 to application 120, specifying that John Doe's total compensation is $210,000.

[0073] Example Method

[0074] Now turn to Fig.12 , which is a flowchart illustrating an example method 1200 for processing database queries from multiple different application versions according to some embodiments. Fig.12The method shown in can be used in combination with any computer circuit, system, equipment, element or assembly and other equipment disclosed herein. In various embodiments, some method elements shown can be performed simultaneously in a different order from that shown, or can be omitted. Additional method elements can also be performed as required.

[0075] At 1210, in the illustrated embodiment, a computer system executing a database management system (DBMS) receives a database query for a database, wherein the database query is received from a specific version of an application having multiple versions, and wherein the database query specifies the specific version. In some embodiments, prior to receiving the database query for the database, the computer system receives an update to the application from the specific version of the application, wherein the update is associated with the specific version. In some embodiments, the computer system changes one or more catalog tables based on the received updates, wherein the changes include changing metadata stored in the catalog tables that specifies that the specific version can access one or more database objects stored in the database. In some embodiments, the update indicates one or more differences between database objects that the specific version can access and database objects that an earlier version of the application can access.

[0076] In some embodiments, the DBMS may receive database queries that do not specify a particular application version. For example, in some cases, the DBMS may know the current application version, and this known application version is used to receive queries unless and until the DBMS receives a SET command (such as a SET command that specifies a different application version). Figure 5A-8 and the SET command shown in 10-11).

[0077] At 1220, the computer system identifies one or more catalog tables, wherein the one or more catalog tables include one or more version information columns storing version access information. In some embodiments, the one or more version information columns include a start version column and a stop version column, which specify a series of application versions that one or more database objects stored in the database can access. For example, the start version column can indicate the application version at which the database object starts to be available, and the stop version column can indicate the application version that can no longer access the database object. In other words, the stop version column can specify the application version (and any later application version) that cannot access the database object. In some embodiments, the version information column specifies version access information for one or more database objects. In some embodiments, the one or more database objects include one or more of the following types of objects: schema, table, column, index, trigger, procedure, and statistics. One or more database objects may include any of the various combinations of object types included in the list, or any of the various other types of database objects not explicitly listed in the above list. For example, the database objects stored in the database may include schema objects and database objects, schema objects or table objects but not both, all seven types of database objects, or any combination thereof. In some embodiments, one of the catalog tables is a schema catalog table that specifies a schema applicable to the one application for at least one application. In some embodiments, a pattern catalog table specifies pattern names that correspond to different applications.

[0078] In some embodiments, a database object can be accessed by a single application version. In other embodiments, a database object can have a lifecycle that spans multiple versions of an application. The lifecycle of a database object can be specified by a start and stop version column. However, in other cases, the lifecycle of a database object can be specified by a single column using an interval data type. In this case, the single column specifies the range of application versions that can access the database object.

[0079] In some embodiments, the version information column specifies version access information for at least schema objects and database table objects of the database, wherein a schema object is a named collection of tables and a database table object is a specific type of table that stores data in a database for an application having multiple versions. In some embodiments, the identified directory tables include a first directory table that defines the version access information in a first format and a second directory table that defines the version access information in a second format. In some embodiments, the first format specifies the version access information as a specific application version and the second format specifies the version access information as a range of application versions.

[0080] At 1230, version access information for the database query is determined by the computer system indicating that one or more database objects corresponding to the database query are accessible to the particular version of the application program.

[0081] At 1240, the computer system accesses one or more database objects that are responsive to the database query and accessible by the specific version of the application based on the determination. In some embodiments, the version access information for the database query allows access to a first portion of the data included in the one or more database objects for the specific version of the application. For example, information stored in the salary column 416 included in the hr.employee table 410 (an example of a database object) can be accessed by the specific version of the application. In some embodiments, in response to receiving additional database queries from different versions of the application, the computing system accesses a second portion of the data included in the one or more database objects based on the version access information of the different versions of the application. For example, information stored in the salary column 416 and the bonus column 418 included in the hr.employee table can both be accessed by different versions of the application. In some embodiments, based on receiving database queries from two different versions of the application and their respective version access information, the computer system accesses different database objects. For example, the computing system can determine that the hr.employee table 410 (an example database object) can be accessed by the first application version, while the customer table (another example database object) can be accessed by the second application version.

[0082] In some embodiments, the computer system adds the index table to the database. In some embodiments, based on adding the index table, the computer system adds a row to the index directory table, the row including metadata for one or more index tables in the database, wherein the row includes respective values ​​for a start version column and a stop version column that specify information indicating one or more versions of an application that can access one or more database objects stored in the database.

[0083] In some embodiments, the specific version of the application transmits a database query to the DBMS for the database, wherein the database query specifies the specific version of the application. In some embodiments, the database maintains version access information in one or more version information columns of one or more directory tables. In some embodiments, the specific version of the application receives data in response to the database query from the DBMS. In some embodiments, data is retrieved from the database based on the version access information that specifies that the specific version of the application can access the data. In some embodiments, the specific version of the application transmits updates to one or more database objects to the DBMS, wherein the updates are associated with the specific version. In some embodiments, the updates include changes to metadata stored in one or more directory tables.

[0084] Example computing device

[0085] Now turn to Fig.13 , depicts a block diagram of a computing device (which may also be referred to as a computing system) 1310 according to some embodiments. Computing device 1310 may be used to implement various portions of the disclosure. Computing device 1310 is an example of a device that may be used as a mobile device, a server computer system, a client computer system, or any other computing system that implements portions of the disclosure. For example, computing device 1310 may implement computing system 110 and / or DBMS 130. In some cases, computing device 1310 executes application 130.

[0086] Computing device 1310 can be any suitable type of device, including but not limited to a personal computer system, a desktop computer, a laptop or notebook computer, a mobile phone, a mainframe computer system, a network server, a workstation, or a network computer. As shown, computing device 1310 includes a processing unit 1350, a storage subsystem 1312, and an input / output (I / O) interface 1330 coupled via an interconnect 1360 (e.g., a system bus). I / O interface 1330 can be coupled to one or more I / O devices 1340. Computing device 1310 also includes a network interface 1332, which can be coupled to a network 1320 for communicating with, for example, other computing devices.

[0087] Processing unit 1350 includes one or more processors, and in some embodiments, one or more coprocessor units. In some embodiments, multiple instances of processing unit 1350 can be coupled to interconnect 1360. Processing unit 1350 (or each processor within processing unit 1350) can include cache or other forms of on-board memory. In some embodiments, processing unit 1350 can be implemented as a general-purpose processing unit, and in other embodiments, it can be implemented as a special-purpose processing unit (e.g., ASIC). In general, computing device 1310 is not limited to any particular type of processing unit or processor subsystem.

[0088] As used herein, the term "processing unit" refers to a circuit configured to perform an operation. Thus, a processing unit can be implemented as a hardware circuit implemented in a variety of ways. The hardware circuit can include, for example, a customized very large scale integration (VLSI) circuit or gate array, an off-the-shelf semiconductor (such as a logic chip, transistor or other discrete components). A processing unit can also be implemented in a programmable hardware device, such as a field programmable gate array, a programmable array logic, a programmable logic device, etc.

[0089] Storage subsystem 1312 can be used by processing unit 1350 (e.g., to store instructions that can be executed by processing unit 1350 and data used by processing unit 1350). Storage subsystem 1312 can be implemented by any suitable type of physical storage medium, including hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDORAM, SDRAM, DDRSDRAM, RDRAM, etc.), ROM (PROM, EEPROM, etc.), etc. In some embodiments, storage subsystem 1312 can be composed only of volatile memory. Storage subsystem 1312 can store program instructions executable by computing device 1310 using processing unit 1350, including program instructions executable to cause computing device 1310 to implement various techniques disclosed herein.

[0090] According to various embodiments, I / O interface 1330 can represent one or more interfaces and can be configured to be coupled to other devices and communicate with other devices in various types of interfaces. In some embodiments, I / O interface 1330 is a bridge chip from the front end to one or more back-end buses. I / O interface 1330 can be coupled to one or more I / O devices 1340 via one or more corresponding buses or other interfaces. Examples of I / O devices include storage devices (hard disks, optical drives, removable flash drives, storage arrays, SANs or associated controllers), network interface devices, user interface devices, or other devices (e.g., graphics, sound, etc.).

[0091] Notice, Fig.13 The computing device of the present invention is one embodiment for demonstrating the disclosed concepts. In other embodiments, various aspects of the computing device may be different. For example, in some embodiments, additional components or multiple instances of the components shown may be included.

[0092] Implementation of the subject matter of the present application includes, but is not limited to, the following Examples 1-20.

[0093] 1. A method comprising:

[0094] receiving, by a computer system executing a database management system (DBMS), a database query to a database, wherein the database query is received from a particular version of an application having a plurality of versions, and wherein the database query specifies the particular version;

[0095] identifying, by the computer system, one or more directory tables, wherein the one or more directory tables include one or more version information columns storing version access information;

[0096] determining, by the computer system, that version access information for the database query indicates that one or more database objects corresponding to the database query are accessible by the particular version of the application; and

[0097] One or more database objects responsive to the database query and accessible to the particular version of the application are accessed by the computer system based on the determination.

[0098] 2. The method of embodiment 1, wherein the one or more version information columns include a version column that specifies information indicating a range of application versions that can access one or more database objects stored in the database.

[0099] 3. A method according to embodiment 1, wherein the version information column specifies version access information of the one or more database objects, and wherein the one or more database objects include one or more of the following types of objects: schema, table, column, index, trigger, procedure and statistics.

[0100] 4. The method according to embodiment 1, further comprising:

[0101] Prior to receiving the database query to the database:

[0102] receiving, by the computer system, an update to the application from the particular version of the application, wherein the update is associated with the particular version; and

[0103] The one or more catalog tables are changed, by the computer system, based on the received update, wherein the change includes changing metadata stored in the catalog tables that specifies one or more database objects stored in the database that the particular version can access.

[0104] 5. The method of embodiment 4, wherein the update indicates one or more differences between the database objects accessible to the particular version and the database objects accessible to an earlier version of the application.

[0105] 6. The method of embodiment 1, wherein one of the catalog tables is a mode catalog table that specifies, for at least one application, a mode applicable to the one application.

[0106] 7. The method of embodiment 1, wherein the version access information for the database query allows access to a first portion of data included in the one or more database objects for the specific version of the application, and wherein the method further comprises:

[0107] In response to receiving an additional database query from a different version of the application, a different second portion of the data included in the one or more database objects is accessed by the computing system based on version access information for the different version of the application.

[0108] 8. The method of embodiment 1, wherein the identified directory table includes a first directory table defining version access information in a first format and a second directory table defining version access information in a second format.

[0109] 9. The method of embodiment 8, wherein the first format specifies the version access information as a specific application version, and wherein the second format specifies the version access information as a range of application versions.

[0110] 10. A non-transitory computer readable medium having stored thereon instructions capable of causing a computing device executing a database management system (DBMS) to perform the following operations, comprising:

[0111] receiving a database query to a database, wherein the database query is received from a particular version of an application having a plurality of versions, and wherein the database query specifies the particular version;

[0112] identifying one or more directory tables, wherein the one or more directory tables include one or more version information columns storing version access information;

[0113] determining that version access information for the database query indicates that one or more database objects corresponding to the database query are accessible by the particular version of the application; and

[0114] Data responsive to the database query and accessible to the particular version of the application is accessed based on the determination.

[0115] 11. The non-transitory computer readable medium of embodiment 10, wherein the one or more version information columns include a start version column and a stop version column that specify a range of application versions that can access one or more database objects stored in the database.

[0116] 12. A non-transitory computer-readable medium according to embodiment 10, wherein the one or more version information columns specify version access information for at least schema objects and database table objects of the database, wherein the schema objects are named collections of tables, and the database table objects are specific types of tables for storing data in the database for the application having the multiple versions.

[0117] 13. The non-transitory computer readable medium of embodiment 10, wherein the operations further comprise:

[0118] Prior to receiving the database query to the database:

[0119] receiving an update to the application from the particular version of the application, wherein the update is associated with the particular version; and

[0120] The one or more catalog tables are changed based on the received update, wherein the change includes changing metadata stored in the catalog tables that specifies one or more database objects stored in the database that the particular version can access.

[0121] 14. A non-transitory computer-readable medium according to embodiment 10, wherein one of the catalog tables is a pattern catalog table that specifies a pattern applicable to at least one application for the one application, and wherein the pattern catalog table specifies pattern names corresponding to different applications.

[0122] 15. The non-transitory computer readable medium of embodiment 10, wherein the operations further comprise:

[0123] adding an index table to the database; and

[0124] Based on adding the index table, a row is added to the index directory table, the row including metadata for one or more index tables in the database, wherein the row includes corresponding values ​​of a start version column and a stop version column, which specify information indicating one or more versions of the application that can access one or more database objects stored in the database.

[0125] 16. The non-transitory computer readable medium of embodiment 10, wherein the version access information of the database query allows access to a first portion of data included in the one or more database objects for the specific version of the application, and wherein the operations further comprise:

[0126] In response to receiving an additional database query from a different version of the application, a different second portion of the data included in the one or more database objects is accessed based on version access information for the different version of the application.

[0127] 17. A method comprising:

[0128] transmitting, by a particular version of the application to a database management system (DBMS), a database query to a database, wherein the database query specifies the particular version of the application, and wherein the database maintains version access information in one or more version information columns of one or more catalog tables; and

[0129] Data is received from the DBMS by the particular version of the application in response to the database query, wherein the data is retrieved from the database based on the version access information specifying one or more database objects accessible by the particular version of the application.

[0130] 18. The method of embodiment 17, further comprising:

[0131] Updates to one or more database objects are transmitted by the particular version of the application to the DBMS, wherein the updates are associated with the particular version, and wherein the updates include changes to metadata stored in the one or more catalog tables.

[0132] 19. The method of embodiment 17, wherein one of the catalog tables is a mode catalog table that specifies, for at least one application, a mode applicable to the one application.

[0133] 20. The method of embodiment 17, wherein the one or more version information columns include a version column that specifies information indicating a range of application versions that can access one or more database objects stored in the database.

[0134] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the disclosure, even in cases where only a single embodiment is described for a particular feature. Unless otherwise specified, the feature examples provided in the disclosure are intended to be illustrative rather than limiting. The above description is intended to encompass such alternatives, modifications, and equivalents as would be apparent to one skilled in the art having the benefit of the disclosure.

[0135] The scope of the disclosure includes any feature or combination of features disclosed herein (explicitly or implicitly) or any generalization thereof, whether or not it alleviates any or all of the problems addressed herein. Accordingly, new claims may be made during the prosecution of the present application (or an application claiming priority thereto) for any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with features of the independent claims, and features from individual independent claims may be combined in any appropriate manner, and not merely in the specific combinations listed in the appended claims.

Claims

1. A method for implementing a database for different application versions, comprising: receiving, by a computer system executing a database management system, a database query to a database, wherein the database query is received from a particular version of an application having a plurality of versions, and wherein the database query specifies the particular version; identifying, by the computer system, one or more catalog tables, wherein the one or more catalog tables include a first column including a start version column and a second, different column including a stop version column, wherein the start version column and the stop version column for a given database object specify a range of application versions accessible to the given database object; determining, by the computer system based on version access information stored in the one or more catalog tables, that one or more database objects corresponding to the database query are accessible by the particular version of the application; and One or more database objects that are responsive to the database query and that are accessible to the particular version of the application are accessed by the computer system based on the determination.

2. The method of claim 1 , wherein the start version column and the stop version column included in a catalog table for a column database object specify a range of two or more application versions accessible by the column database object, the column database object being included in a database table object stored in the database.

3. The method according to claim 1 or 2, wherein the start version column and the stop version column specify version access information of one or more of the following types of objects: schema, table, column, index, trigger, procedure, and statistics.

4. The method according to claim 1, further comprising: Prior to said receiving a database query to said database: receiving, by the computer system, an update to the application from the particular version of the application, wherein the update is associated with the particular version; and The one or more catalog tables are changed, by the computer system, based on the received update, wherein the change includes changing metadata stored in the catalog tables, the metadata specifying one or more database objects stored in the database that the particular version can access.

5. The method of claim 4, wherein the update indicates one or more differences between database objects accessible to the particular version and database objects accessible to an earlier version of the application. 6 . The method of claim 1 , wherein one of the catalog tables is a mode catalog table that specifies, for at least one application, a mode applicable to the at least one application.

7. The method of claim 1 , wherein the version access information for the database query allows access to a first portion of data included in the one or more database objects for the specific version of the application, and wherein the method further comprises: In response to receiving an additional database query from a different version of the application, a different second portion of the data included in the one or more database objects is accessed by the computer system based on version access information for the different version of the application.

8. The method of claim 1, wherein the identified directory table comprises a first directory table defining version access information in a first format and a second directory table defining version access information in a second, different format.

9. The method of claim 8, wherein the first format specifies version access information as a specific application version, and wherein the second, different format specifies version access information as a range of application versions.

10. A computer system comprising: at least one processor; and A memory having program instructions stored thereon, wherein the program instructions can be executed by the at least one processor to perform the method according to any one of claims 1 to 9.

11. A non-transitory computer-readable medium having instructions stored thereon, the instructions enabling a computing device executing a database management system to perform operations including: receiving a database query to a database, wherein the database query is received from a particular version of an application having a plurality of versions, and wherein the database query specifies the particular version; identifying one or more catalog tables, wherein the one or more catalog tables include a first column including a start version column and a second, different column including a stop version column, wherein the start version column and the stop version column for a given database object specify a range of application versions that the given database object is able to access; determining, based on version access information stored in the one or more catalog tables, that one or more database objects corresponding to the database query are accessible by the particular version of the application; and Data responsive to the database query and accessible to the particular version of the application is accessed based on the determination.

12. The non-transitory computer-readable medium of claim 11, wherein the start version column and the stop version column included in a catalog table for a column database object specify a range of two or more application versions accessible by the column database object, the column database object being included in a database table object stored in the database.

13. The non-transitory computer-readable medium of claim 11 or 12, wherein the start version column and the stop version column specify version access information for at least schema objects and database table objects of the database, wherein the schema objects are named collections of tables, and the database table objects are tables of a specific type for storing data in the database for the application having the multiple versions.

14. The non-transitory computer readable medium of claim 11, wherein the operations further comprise: Prior to receiving a database query to said database: receiving an update to the application from the particular version of the application, wherein the update is associated with the particular version; and The one or more catalog tables are changed based on the received update, wherein the changing includes changing metadata stored in the catalog tables, the metadata specifying one or more database objects stored in the database that the particular version can access.

15. The non-transitory computer-readable medium of claim 11, wherein one of the catalog tables is a pattern catalog table that specifies, for at least one application, a pattern applicable to the at least one application, and wherein the pattern catalog table specifies pattern names corresponding to different applications.

Images