Mechanism for handling schema changes

Abstract

Techniques related to database schema are disclosed. A computer system may receive a metadata document describing an updated schema for a database storing a plurality of records. The computer system may instantiate a set of processes to execute an upgrade routine to upgrade some of the plurality of records to conform to the updated schema. While the set of processes are upgrading the records, the computer system may receive a request to perform an operation on one of the plurality of records. The computer system may detect that the record corresponds to a schema version earlier than the updated schema version of the metadata document and may upgrade the record to conform to the updated schema. After upgrading the record, the computer system may perform the requested operation on the record.

Description

Technical Field

[0001] This disclosure generally relates to database systems, and more specifically to various mechanisms for enabling changes to metadata documents without stopping the database service.

Background Art

[0002] Companies routinely implement a database management system (or simply "database system") that enables the storage of a collection of information in an organized manner that can be efficiently accessed and manipulated by users. In some cases, the database system implements a key-value database that stores information as a set of key-value pairs, where the key serves as a unique identifier for accessing its associated value. During operation, the database system receives requests from users via an application or from other systems such as another database system, and executes transactions on the information stored in its key-value database. To that end, the database system reads information from the database and / or writes information back to the database using the keys specified in those requests.

Brief Description of the Drawings

[0003] [Figure 1] A block diagram showing exemplary elements of a system having a database store and database nodes, according to some embodiments. [Figure 2] A block diagram showing exemplary elements of a metadata document that describes a set of database entities, according to some embodiments. [Figure 3A] A block diagram showing exemplary elements of a database application that processes a transaction including writing a record, according to some embodiments. [Figure 3B]This block diagram shows exemplary elements of a database application that handles transactions, including returning records, according to several embodiments. [Figure 4] This block diagram shows exemplary elements of a database node capable of refreshing its cache to store updated metadata documents, according to several embodiments. [Figure 5] This flowchart illustrates exemplary methods for upgrading records as part of processing a transaction, according to several embodiments. [Figure 6] This flowchart illustrates exemplary methods for upgrading records as part of processing a transaction, according to several embodiments. [Figure 7] This is a block diagram showing the elements of a multitenant system in several embodiments. [Figure 8] This block diagram shows the elements of a computer system for implementing the various systems described in this disclosure, according to several embodiments. [Modes for carrying out the invention]

[0004] A database system may implement a key-value database, which stores data as a collection of key-value pairs. This key-value database typically provides little to no support for checking or enforcing rules regarding what data can be written to the database. For example, a database may not support a "strongly typed" schema that defines the types and structures of data that are permitted to be written to the database. As a result, without enforcement of a strongly typed schema, one application may write data to the database, and then another application may access that data expecting it to contain certain values ​​or be formatted in a specific way, but it may not. Therefore, the other application may not be able to function correctly with that data. Because the database does not provide this support, the responsibility to ensure that data is stored and properly structured before being read later rests with the database client / user, not the provider. This makes it easier for database system providers to adopt key-value databases, but places an additional burden on the client to ensure that data is written according to the schema. To alleviate this burden on the client, it would be desirable to implement a schema management layer that sits on top of the key-value database and provides support for a strongly typed schema. Furthermore, it would be desirable to enable clients to update schemas without experiencing excessive performance degradation. This disclosure addresses, in particular, the issue of how to implement a schema management layer so that clients / tenants can update schemas without interrupting any part of the database to implement the updates.

[0005] In the various embodiments described below, the computer system includes a database store and database nodes that run processes to serve transaction requests from clients of the computer system. The database nodes can ensure that data is manipulated (e.g., accessed, stored, etc.) according to a schema described in a metadata document. During operation, the database nodes may receive schema update requests specifying a metadata document describing an updated schema. In response to a request, in various embodiments, the database node instantiates a set of upgrade processes that run upgrade routines to upgrade the data in the database store to conform to the schema. For example, the updated schema may add a new field to a user table. The upgrade processes may upgrade the records in that user table so that those records include the value of the new field. However, while those upgrade processes are upgrading the records, the database nodes may receive requests to run transactions that include records of the database entities being upgraded. Before performing the requested action on the records, in various embodiments, the database node determines whether the version of the record matches the version of the updated schema, since the record may not yet have been reached by the upgrade processes. If there is a mismatch between the versions, the database node performs a set of steps to upgrade the record to conform to the updated schema. Once the record is upgraded, the database node can perform the requested action on the record.

[0006] In various embodiments, a metadata document identifies the status of one or more database entities described by a schema. While a database entity is being created or upgraded, its status can be set to reflect these processes, and when creation / upgrade is complete, the status can be updated to indicate that the database entity is ready. In various embodiments, the status described in the metadata document can be queried by a client to determine whether a particular database entity (e.g., an index) is available. Once the client determines that the database entity is ready, it can initiate a transaction request to utilize that database entity. In some embodiments, the transaction request may specify the minimum schema version to be used to process the request. Therefore, when processing the request, the database node can determine whether the schema version cached in the database node's memory meets the minimum schema version. If the minimum schema version is not met, in various embodiments, the database node replaces the cached schema with the schema described in the most recent metadata document. Thus, the client can use the minimum schema version to cause the database node to refresh its cache (if it hasn't already).

[0007] These techniques can be advantageous because they allow for the implementation of a “schema management layer” that provides strong typing through schemas, which can be updated without unduely impacting clients while records are being upgraded to conform to that schema. Consider an example where a client updates the schema of a table to add a new field. The schema management layer can upgrade records as soon as they are requested or manipulated by the client, so the client can continue to access records in the table while the table is being upgraded. Thus, the client would not need to wait for updates to propagate throughout the table before interacting with it. Furthermore, by tracking the status of different database entities described in the schema, the client can determine whether a particular entity, such as a new index, is available. In addition, by using a minimum schema version in transaction requests, the client can ensure causal consistency by having the database node refresh its cache and make the latest version available when appropriate. Here, we will first describe an exemplary application of this technique with reference to Figure 1.

[0008] Referring now to Figure 1, a block diagram of system 100 is shown. System 100 includes a set of components that can be implemented through hardware or a combination of hardware routines and software routines. In the illustrated embodiment, system 100 includes a database store 110 and a database node 120 that interacts with the database store 110 and a client 121. Further as shown, the database store 110 includes records 112 and metadata documents 114, and the database node 120 includes a database application 130 and an in-memory cache 140 used to cache the metadata documents 114. Also, as shown, the database application 130 includes a schema engine 135 that can spawn one or more upgrade processes 137. In some embodiments, system 100 is implemented differently from the illustration. For example, system 100 may include multiple database nodes 120 that collectively implement database services, the database store 110 may store multiple metadata documents 114, and / or multiple clients 121 may interact with the database node 120. As another example, metadata document 114 may be stored in a metadata store separate from database store 110.

[0009] In various embodiments, System 100 implements a platform service (e.g., a customer relationship management (CRM) platform service) that enables users of its service to develop, run, and manage applications. System 100 may be a multitenant system that provides various functions to users / tenants hosted by a multitenant system. Thus, System 100 may execute software routines from various different users (e.g., providers and tenants of System 100) and provide code, web pages, and other data to users, databases (e.g., database store 110), and entities associated with System 100 (e.g., third-party systems). In various embodiments, System 100 is implemented using cloud infrastructure provided by a cloud provider. Thus, the database store 110 and database node 120 may run on and utilize available cloud resources (e.g., computing resources, storage resources, network resources, etc.) of that cloud infrastructure to facilitate their operation. For example, database node 120 may run in a virtual environment hosted on server-based hardware included in the cloud provider's data center. However, in some embodiments, the system 100 is implemented using local or private infrastructure, as opposed to a public cloud.

[0010] In various embodiments, the database store 110 includes a collection of information organized to enable access, storage, and manipulation of the information. The database store 110 may include support software (e.g., storage node) that enables database nodes 120 to perform these operations (e.g., access, storage, etc.) on the information stored in the database store 110. In various embodiments, the database store 110 is implemented using one or more storage devices connected to each other on a network (e.g., a storage-attached network (SAN)) and configured to store information redundantly to prevent data loss. The storage devices can permanently store data, and therefore the database store 110 can function as persistent storage for the system 100. In various embodiments, data written to the database store 110 by database node 120 is accessible to other database nodes 120 in a multi-node configuration.

[0011] In various embodiments, data is stored in the database store 110 in records 112 structured according to one or more schemas described in a metadata document 114. In some cases, system 100 may implement a relational database, and therefore the metadata document 114 may describe tables, views, indexes, relationships, triggers, etc. Thus, a record 112 may correspond to a row in a database table and specify the value of one or more fields in that table. One or more of the fields may be used to define a key for accessing that record from the database store 110. In various cases, system 100 may implement a non-relational database such as a key-value store, a wide-column store, or a document store, and therefore the metadata document 114 may describe the properties and / or constraints of an item / record 112 stored in the database store 110. For example, a record 112 may be a key-value pair containing data and a corresponding key that can be used to look up that record 112. Thus, the metadata document 114 may describe a set of fields in which the record 112 is expected to store values. Therefore, in various embodiments, the metadata document 114 is a monolithic document that describes the organization of the data as a blueprint for how the database store 110 should be constructed. An exemplary metadata document 114 is described in more detail with respect to Figure 2.

[0012] In various embodiments, the database node 120 provides various database services, such as data storage, data retrieval, and data manipulation. The database node 120 can be a combination of hardware and software (e.g., a database application 130) running on that hardware. In various embodiments, the database application 130 can be configured to provide the database services of the database node 120 to components within and / or outside of the system 100. For example, as shown, the database node 120 can receive transaction requests 122 from a client 121 (e.g., an application server, a user device, another database node, etc.) (e.g., via an API such as Java® Database Connectivity) to execute transactions. A database transaction is, in various embodiments, a logical unit of work (e.g., a specified set of database operations) to be performed in relation to the database store 110. For example, processing a database transaction may involve executing a SELECT command to select a set of rows from a set of tables. The content of the rows may be specified in a record 112, and therefore the database node 120 may return the record 112 corresponding to those rows. As another example, processing a database transaction may involve writing a set of documents, in the form of records 112, to a collection stored in the database store 110. In some embodiments, the database node 120 first writes the records 112 to the in-memory cache 140 and then flushes them to the database store 110 after they have been committed. As used herein, the expression “commit a transaction” is used in its commonly understood sense and refers to the process of saving the changes made during a transaction and making them visible outside of the entity that performed the transaction.

[0013] As part of processing database transactions, in various embodiments, the database node 120 ensures that data is managed according to a set of schemas described in the metadata document 114. In particular, the database store 110 may be a key-value store that does not provide support for strong typing, although strong typing may still be desired by the client 121. Therefore, in various embodiments, the database node 120 allows the client 121 to define a framework for structuring and accessing the data, and the database node 120 then enforces that framework, resulting in strong typing. Thus, in various embodiments, the database node 120 implements the schema management layer described above. To process transactions potentially more efficiently, the database node 120 may cache the metadata document 114 in its in-memory cache 140, as shown in the figure.

[0014] In various embodiments, the in-memory cache 140 is a buffer that stores data in the memory of the database node 120 (e.g., random access memory). The in-memory cache 140 may be located in a shared memory area specified by the operating system running on the database node 120 and may be accessible to the database process of the database node 120 (e.g., upgrade process 137). Thus, when processing a transaction request 122, the database application 130 can access the metadata document 114 from the in-memory cache 140 and then process the requested transaction, taking the metadata document 114 into consideration. As will be described in more detail with respect to Figure 4, the metadata document 114 cached in the in-memory cache 140 may be a different version from the one stored in the database store 110. Thus, in various embodiments, the database node 120 refreshes the in-memory cache 140 to cache the latest metadata document 114 after a refresh period or in response to a transaction request 122.

[0015] To create or update a schema(s) described in a metadata document 114, client 121 may send a schema request 126 to the database node 120, as shown in the figure. The schema request 126 may include a new metadata document 114 used to replace a metadata document stored in the database store 110. The new metadata document 114 may define a new database entity (e.g., an index) and / or update an existing database entity described in the previous metadata document 114 (e.g., add a field to a table). In various embodiments, the database node 120 supplements the metadata documents 114 with status information that identifies the status of the database entities described in those metadata documents 114. Thus, in some cases, client 121 may issue a schema request 126 to determine the status of a particular database entity. The database node 120 may send a schema response 128 to its client 121 that includes a display of the metadata documents 114 or the status of those database entities. The database node 120 may also provide a schema response 128 that identifies the latest version of the metadata document 114, enabling the client 121 to issue a transaction request 122 that utilizes that metadata document 114 (for example, by specifying the minimum version). After receiving the new metadata document 114, the database node 120 may run the schema engine 135 to upgrade the system 100 to conform to the new metadata document 114.

[0016] In various embodiments, the schema engine 135 facilitates the upgrade / migration of a set of records 112 to conform to a metadata document 114. As shown in the figure, the schema engine 135 can instantiate a set of upgrade processes 137. In various embodiments, the upgrade processes 137 walk through and upgrade the records 112 associated with database entities that have been updated or created in a particular metadata document 114. For example, the metadata document 114 may describe a new index on a table, and therefore the upgrade process 137 may walk through and process the records 112 of that table to create the new index. As part of processing the records 112, the upgrade process 137 may update the version of the records 112 to match the version in a particular metadata document 114. While the upgrade process 137 is processing the records 112, the database node 120 may continue to service transaction requests 122.

[0017] In various cases, while the upgrade process 137 is processing records 112, the database node 120 may receive transaction requests 122 to perform an operation on a particular set of records 112. The database node 120 may access those records 112 and determine that one or more of them have not yet been upgraded by the upgrade process 137. In response, the database node 120 may first upgrade the records 112 based on its cached metadata document 114, and then perform the requested operation on those records 112. An example of upgrading records 112 as part of a read / access request is illustrated with reference to Figure 3A, and an example of upgrading records 112 as part of an update / write request is illustrated with reference to Figure 3B.

[0018] Referring to Figure 2, a block diagram of metadata document 114 is shown. In the illustrated embodiment, metadata document 114 describes database entities 200A-C, status 205, and version 210. As shown in the illustration, each of the database entities 200A-C includes their respective status 205. In some embodiments, metadata document 114 is implemented differently from that shown. For example, database entity 200 may specify version 210.

[0019] A database entity 200 is, in various embodiments, a database construct or structure that facilitates the implementation of the database. For example, a database entity 200 may be a table, index, package, procedure, function, trigger, view, sequence, or link. A database entity 200 is formally defined in a metadata document 114 and is created and managed based on that formal definition. Thus, in various embodiments, in order to create or update a database entity 200, the new / updated database entity 200 is described in a metadata document 114 that is submitted to the database node 120 via a schema request 126. The submitted metadata document 114 may replace an existing metadata document 114 in the database store 110. The database node 120 can then perform the update / creation of the appropriate database entity 200. To track the current state of a database entity 200, a database entity 200 can be associated with a status 205, as shown in the figure.

[0020] Status 205 indicates the current state of an entity in various embodiments. Examples of states may include “Creating,” “Updating,” and “Ready.” Status 205 can be used by client 121 to determine whether the database entity 200 can be used to process a transaction request 122 from client 121. For example, client 121 may submit a metadata document 114 describing a new view database entity 200 based on a set of tables. While that view database entity 200 is being created, its status 205 may be set to “Creating” by the database node 120. Therefore, when client 121 polls the database node 120 for status 205 (for example, via a schema request 126), client 121 may determine that the view database entity 200 is not ready and therefore may not submit a transaction request 122 that utilizes the view database entity 200. When client 121 observes that status 205 has been set to "Ready", client 121 may initiate a transaction request 122 that utilizes view database entity 200.

[0021] In various cases, database entity 200 may depend on another database entity 200. For example, database entity 200A may correspond to a database table, and database entity 200B may correspond to an index built based on that table. Thus, in some embodiments, the status 205 of database entity 200 may be set in response to changes made to another database entity 200. For example, database entity 200C may correspond to a new index based on the table of database entity 200A. While that index is being built, the status 205 of database entity 200A may be set to "pending" to indicate that database entity 200A is in use. This may prevent database entity 200A from being deleted or its structure from being changed. When the index is ready, the status 205 of database entities 200A and 200C may be set to "ready".

[0022] As shown in the illustration, metadata document 114 includes a status 205. This status 205 can indicate whether all database entities 200 are ready or whether at least one database entity 200 is still being created or updated. In various embodiments, database entities 200 are created or updated at least partially in parallel by system 100. However, in some embodiments, database entities 200 are created or updated sequentially. For example, metadata document 114 can describe new fields for database entity 200B and new database entity 200C. Database node 120 can update record 112 of database entity 200B before creating physical database entity 200C. As a result, some database entities 200 may be ready for use before other database entities 200, and the status 205 of metadata document 114 can be used to indicate when all database entities are ready.

[0023] As further shown, metadata document 114 includes a version 210. The version 210, in various embodiments, identifies a value indicating the progress of metadata document 114. Thus, the version 210 of a given metadata document 114 can be used to determine whether that metadata document 114 is a previous version or a later version of another metadata document 114. The version 210 can further enable a client 121 to ensure that a particular database entity 200 is available for processing a transaction request 122. For example, client 121 can specify a minimum schema version in transaction request 122, and database node 120 can compare that minimum version to the version 210 of the metadata document 114 cached in in-memory cache 140.

[0024] Next, referring to Figure 3A, a block diagram is shown in which the database application 130 processes a transaction that includes writing record 112. In the illustrated embodiment, there is a database store 110, a database application 130, and an in-memory cache 140. As shown, the database store 110 includes record 112A with version 210A "1.2" and records 112B-D with versions 210B-D "1.1". Furthermore, as shown, the database application 130 includes a transaction process 320 and a schema engine 135 that implements an upgrade process 137. Also, as shown, the in-memory cache 140 includes a metadata document 114. The illustrated embodiment may be implemented in ways other than those shown. For example, there may be a metadata store that also stores the metadata document 114.

[0025] As described, the database node 120 can receive a schema request 126 specifying a new metadata document 114. In response to receiving that request, in various embodiments, the schema engine 135 instantiates a set of upgrade processes 137 to perform a migration scan 305 on records 112 corresponding to the changes described in the new metadata document 114. In some cases, all records 112 stored in the database store 110 are scanned as part of the migration scan 305. In some embodiments, the schema engine 135 may wait for a certain period before starting the migration scan 305 so that the in-memory cache 140 can be cleared. The scanned records 112 can be migrated to conform to the schema(s) described in the new metadata document 114.

[0026] As part of the migration scan 305, in some embodiments, the upgrade process 137 accesses record 112 (of the database entity 200 being upgraded) using metadata corresponding to version 210 of that record, upgrades record 112 based on the metadata of the new metadata document 114, and then performs an "on-disk" migration, writing record 112 back to the database store 110. Read-write round trips may not be atomic because another concurrent write may occur after a record is read and before it is written. Therefore, in various embodiments, the writeback of a record is conditional on the record not having changed since it was accessed by the upgrade process 137. This condition may relate to attributes that did not exist in the original record.

[0027] In some cases, a set of upgrade processes 137 may miss records 112 that should be upgraded, for example, if database node 120 crashes. To ensure that all relevant records 112 are upgraded, in some embodiments, database node 120 generates a set of scrutiny processes that traverse records 112 and move any records 112 that were not upgraded by upgrade process 137 but should have been upgraded. The scrutiny processes may be generated periodically or after reaching a migration point (for example, after the completion of migration scan 305).

[0028] In various embodiments, the transaction process 320 is an executable computer process for providing various database services to the database node 120. The transaction process 320 can be instantiated to process a transaction request 122 passed by the client 121 over an established database connection. As part of processing the transaction request, the transaction process 320 can execute a set of database statements specified in that request. To execute those database statements, in various embodiments, the transaction process 320 executes a query execution plan that defines a sequence of steps to be performed to satisfy the database statements. Thus, the transaction process 320 can access the definition of the query execution plan (for example, in database 110), compile it into an executable form, and then execute the compiled form.

[0029] In various cases, while a set of upgrade processes 137 is performing a migration scan 305, the database application 130 may receive a transaction request 122 that performs a transaction involving writing a record 112 to a database entity 200 that is being created or updated. As a result, in various embodiments, the database application 130 ensures that the record 112 (which may be a new record or an update) conforms to the metadata document 114 in its in-memory cache 140. As will be described in more detail with respect to Figure 4, the database node 120 may periodically refresh its in-memory cache 140 to store the most recent metadata document 114. If the record 112 to be written is a new record, the database node 120 may write the record 112 to the database store 110 according to the cached metadata document 114.

[0030] If the record 112 to be written is an update, the transaction process 320 may access the existing record 112. For example, transaction request 122 may provide an update to record 112C, and therefore the transaction process 320 may access record 112C as shown in the figure. If version 210 of the accessed record 112 matches the version of the metadata document 114 cached in the in-memory cache 140, the transaction process 320 writes the updated record 112 to the database store 110. If there is a version mismatch, the transaction process 320 may perform a set of steps to upgrade the existing record 112 to the version in the metadata document 114. For example, if the metadata document 114 adds a field to the database table containing the accessed record 112, the transaction process 320 may upgrade record 112 to include the value of that field. In some embodiments, the transaction process 320 writes the upgraded record 112 back to the database store 110 and then retries the request. In other embodiments, the transaction process 320 writes the requested updates to the upgraded record 112 and writes the record 112 to the database store 110. In various embodiments, the transaction process 320 further updates the version of record 112. For example, when record 112C is first accessed, its version 210C is "1.1" (as it may not have been upgraded yet by a set of upgrade processes 137), but the version of the cached metadata document 114 may be "1.2". Therefore, the transaction process 320 may upgrade record 112C to version "1.2" and then perform the requested action on the upgraded record 112C.

[0031] Other database operations that are conditional (for example, deleting record 112 if its property "foo" value is equal to "blah") may include upgrading record 112 before performing the database operation. For example, a metadata document 114 may add a field "foo" to a database table, and a database application 130 may receive a request to delete any record 112 in that database table where the value of "foo" is "blah". If record 112 has not been upgraded to have the value of that field, in various embodiments, the database application 130 will upgrade record 112 to have the value of that field so that the delete operation can be performed. A replacement operation that replaces a particular record 112 with another record 112 is another example of a database operation that may be conditional and therefore include upgrading record 112. In some embodiments, if the requested operation is not conditional, the database application 130 may perform the requested operation without upgrading the relevant record 112. Instead, a set of upgrade processes 137 may upgrade record 112 when it is reached during a migration scan 305.

[0032] Next, referring to Figure 3B, a block diagram is shown showing how the database application 130 handles a transaction that includes returning record 112. In the illustrated embodiment, there is a database store 110, a database application 130, and an in-memory cache 140. As shown, the database store 110 contains record 112A with version 210A "1.2" and records 112B-D with versions 210B-D "1.1". Furthermore, as shown, the database application 130 includes a transaction process 320 and a schema engine 135 that implements an upgrade process 137. Also, as shown, the in-memory cache 140 contains a metadata document 114. The illustrated embodiment may be implemented in ways other than those shown. For example, there may be a metadata store that also stores the metadata document 114.

[0033] In some cases, the database application 130 receives a transaction request 122 that returns one or more records 112 stored in the database store 110. Similar to writing a record 112, the transaction process 320 may access the record 112, determine whether its version 210 is the same as the version in the cached metadata document 114, and then upgrade the record 112 (if applicable) before returning it to the requester. Instead of performing an "on-disk" migration, in various embodiments, the transaction process 320 performs an "in-memory" migration in which the record 112 is upgraded but not written back to the database store 110. For example, record 112C may be upgraded in the database application 130 to conform to the accessed and cached metadata document 114, but without being written to the database store 110; rather, a set of upgrade processes 137 may perform an on-disk migration in which record 112C is upgraded and written to the database store 110. However, in some embodiments, the transaction process 320 may upgrade the record 112, return it to the requester (for example, via the transaction response 124), and then write it to the database store 110.

[0034] Referring to Figure 4, a block diagram of a database node 120 is shown, which refreshes its in-memory cache 140 to store the updated metadata document 114. In the illustrated embodiment, there are two database nodes 120A-B and a database store 110. As shown, both database nodes 120A-B initially cache metadata document 114A with version 210A "1.1", and the database store 110 stores metadata document 114B with version 210B "1.2". Further as shown, the database store 110 stores record 112 with version 210 "1.1". The illustrated embodiment may be implemented in a different manner than shown. For example, the two database nodes 120A-B may not exist.

[0035] As described, in some embodiments, the database node 120 may receive a schema request 126 that includes an updated metadata document 114. However, in various embodiments, a metadata endpoint is provided to which the updated metadata document 114 can be submitted and stored by a metadata server (not shown). As a result, the metadata document 114 cached by the database node 120 may temporarily be an older version than the metadata document 114 stored in the database store 110. As mentioned above, the database node 120 may process a transaction request 122 according to the metadata document 114 in its in-memory cache 140. As a result, the transaction request 122 may be processed according to the metadata document 114 associated with the older version.

[0036] In various embodiments, to ensure that the database node 120 uses at least a specific version, the client 121 may specify a minimum schema version in its transaction requests 122. As shown in the figure, for example, transaction request 122A specifies a minimum schema version "1.1". Since metadata document 114A has version 210A "1.1", the database node 120A may process transaction request 122A using metadata document 114A instead of refreshing its in-memory cache 140. Therefore, if transaction request 122A attempts to access the illustrated record 112, the database node 120A may access record 112, determine that its version 210 matches the version in metadata document 114A, and return record 112 without upgrading it. In contrast to transaction request 122A, transaction request 122B specifies a minimum version "1.2". Since the metadata document 114A stored in database node 120B is smaller than the minimum version, database node 120B accesses metadata document 114B and replaces metadata document 114A with metadata document 114B in its in-memory cache 140.

[0037] Next, database node 120B may process transaction request 122B. If transaction request 122B attempts to access record 112, database node 120B may access record 112, determine that its version 210 is different from the version of metadata document 114B, and upgrade record 112 to version "1.2". Then, database node 120B may return the upgraded record 112 to the requester and / or write that record 112 back to database store 110. Thus, client 121 may cause database node 120 to use at least the minimum metadata document version. To determine the latest metadata document version, in various embodiments, client 121 issues a schema request 126 to database node 120 or the metadata server to access the latest metadata document 114. The metadata document 114 may be returned to client 121, which may extract version 210 of the metadata document 114 and then include version 210 in a subsequent transaction request 122 to database node 120.

[0038] Referring now to Figure 5, a flowchart of Method 500 is shown. Method 500 is one embodiment of a method performed by a computer system (e.g., System 100) in which a set of records (e.g., Record 112) is upgraded as part of processing a transaction. Method 500 can be performed by executing a set of program instructions stored in a non-temporary computer-readable medium. In some embodiments, Method 500 includes more or fewer steps than those illustrated. For example, Method 500 may include the step of the computer system writing the upgraded records to a database (e.g., Database Store 110).

[0039] Method 500 begins in step 510 with the computer system receiving a metadata document (e.g., metadata document 114) (e.g., from client 121) describing an updated schema for a database that stores multiple records. The updated schema may describe a set of database entities (e.g., database entities 200) and a corresponding set of statuses (e.g., statuses 205). In various embodiments, the statuses indicate whether the corresponding entity is available to process a request (e.g., transaction request 122). In response to receiving a status request (e.g., schema request 126) from a client (e.g., client 121) requesting the status of a particular one of the set of database entities, the computer system may return a response (e.g., schema response 128) indicating the status of that particular database entity. In various embodiments, the client can operate to use the response to determine whether a particular database entity is available to process a request from the client.

[0040] In step 520, the computer system instantiates a set of processes (e.g., upgrade process 137) to execute an upgrade routine for upgrading multiple records to conform to the updated schema. The updated schema may describe a set of updates to a set of database entities, and the first database entity of the set may be migrated before the second database entity of the set so that the first database entity is available for processing requests before the second database entity becomes available.

[0041] In step 530, while a set of processes is upgrading multiple records, the computer system receives a request (e.g., transaction request 122) to perform an action on one of the multiple records. The request may specify multiple actions and / or multiple records. In some embodiments, the request specifies the minimum schema version to be used when processing the received request. The computer system may detect that the schema stored in the computer system's memory (e.g., in-memory cache 140) does not meet the minimum schema version. Therefore, the computer system may replace the stored schema in memory with the updated schema.

[0042] In step 540, the computer system detects that a record corresponds to an earlier schema version than the updated schema version in the metadata document. In step 550, the computer system upgrades the record to conform to the updated schema. In some cases, one of the set of database entities may be an index, and the computer system may update the status of the table on which that index is based in the metadata document. The updated status of the table may prevent the table from being dropped while the index is being created. In some cases, the updated schema may describe an index that was not described in the previous schema version. Therefore, upgrading a record to conform to the updated schema may involve populating the index with entries for the record and, after populating the index, updating the record's version (e.g., version 210) to match the updated schema version.

[0043] In step 560, after upgrading the record, the computer system performs the requested action on the record. In some cases, the record may be returned to the request issuer without being upgraded and stored in the database. Thus, the record may then be upgraded by one of a set of processes and stored in the database. After the set of processes completes the upgrade routine, in some embodiments, the computer system may instantiate a set of scrutiny processes to determine whether all of the multiple records have been upgraded to conform to the updated schema.

[0044] Referring now to Figure 6, a flowchart of Method 600 is shown. Method 600 is one embodiment of a method performed by a computer system (e.g., System 100) in which a set of records (e.g., Record 112) is upgraded as part of processing a transaction. Method 600 can be performed by executing a set of program instructions stored in a non-temporary computer-readable medium. In some embodiments, Method 600 includes more or fewer steps than those illustrated. For example, Method 600 may include the step of the computer system writing the upgraded records to a database (e.g., Database Store 110).

[0045] Method 600 begins in step 610 with the computer system receiving a metadata document (e.g., metadata document 114) describing an updated schema for a database that stores multiple records. In various embodiments, the computer system instantiates a set of processes (e.g., upgrade process 137) to perform an upgrade routine for upgrading the multiple records to conform to the updated schema. The updated schema may describe a set of database entities (e.g., database entities 200) and a corresponding set of statuses (e.g., status 205). For one of the set of database entities, the computer system may set the status of the database entity to indicate that the database entity has been upgraded. In some embodiments, the status is observable by a client capable of issuing database requests to the system.

[0046] In step 620, the computer system receives a request (e.g., transaction request 122) to perform an operation on one of several records. The request may specify a minimum schema version, and the computer system may determine that the version of the schema cached in the system cache (e.g., in-memory 140) is less than the minimum schema version, and then replace the cached schema with the updated schema in the cache.

[0047] In step 630, the computer system detects that a record corresponds to an earlier schema version than the updated schema version in the metadata document. In step 640, the computer system upgrades the record to conform to the updated schema. In some cases, the updated schema adds additional fields to the database tables in the database. A record may correspond to a table, and therefore updating a record may involve modifying the record to include the values ​​of the additional fields and updating the record's version (e.g., version 210) to match the updated schema version.

[0048] In step 650, after upgrading a record, the computer system performs the requested action on the record. In some cases, performing the requested action may include deleting the upgraded record from the database. The computer system may receive another request to perform an action on a different record among several records. The other request may not specify a minimum schema version. Before refreshing its cache with the updated schema, the computer system may perform the action of the other request on a different record without upgrading the different record that may correspond to a schema version older than the updated schema version.

[0049] Exemplary multitenant database system Referring next to Figure 7, an exemplary multitenant database system (MTS) 700 is shown that can implement various techniques of the present disclosure, for example, system 100 may be MTS 700. In Figure 7, MTS 700 includes a database platform 710, an application platform 720, and a network interface 730 connected to a network 740. Also as shown, the database platform 710 includes data storage 712 and a set of database servers 714A-N that interact with the data storage 712, and the application platform 720 includes a set of application servers 722A-N, each having its own environment 724. In the illustrated embodiment, MTS 700 is connected to various user systems 750A-N via the network 740. The disclosed multitenant system is included for illustrative purposes only and is not intended to limit the scope of the present disclosure. In other embodiments, the techniques of the present disclosure are implemented in non-multitenant environments such as client / server environments, cloud computing environments, and clustered computers.

[0050] In various embodiments, the MTS700 is a set of computer systems that together provide various services to users (alternatively referred to as “tenants”) who interact with the MTS700. In some embodiments, the MTS700 implements a customer relationship management (CRM) system that provides tenants (e.g., businesses, government agencies, etc.) with mechanisms for managing relationships and interactions with customers and potential customers. For example, the MTS700 may enable tenants to store customer contact information (e.g., customer websites, email addresses, phone numbers, and social media data), identify sales opportunities, record service issues, and manage marketing campaigns. Furthermore, the MTS700 may enable these tenants to identify how they communicated with customers, what customers purchased, when customers last purchased items, and how much customers paid. To provide CRM system services and / or other services, the MTS700 includes a database platform 710 and an application platform 720, as shown in the figure.

[0051] In various embodiments, the database platform 710 is a combination of software routines and hardware elements that implement database services for storing and managing data of the MTS 700, including tenant data. As shown in the figure, the database platform 710 includes data storage 712. In various embodiments, the data storage 712 includes a set of storage devices (e.g., solid-state drives, hard disk drives, etc.) connected to each other over a network (e.g., a Storage Attached Network (SAN)) and configured to store data redundantly to prevent data loss. In various embodiments, the data storage 712 is used to implement a database (e.g., a database store 110) containing a collection of information organized in a way that enables access, storage, and manipulation of the information. The data storage 712 may implement a single database, a distributed database, a collection of distributed databases, a database with redundant online or offline backups or other redundancy, etc. As part of implementing the database, the data storage 712 may store files containing one or more database records, each having a data payload (e.g., values ​​of fields in a database table) and metadata (e.g., key values, timestamps, table identifiers for tables associated with the record, tenant identifiers for tenants associated with the record, etc.).

[0052] In various embodiments, database records may correspond to rows in a table. A table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Thus, each record in a table may contain an instance of data for each category defined by its fields. For example, a database may contain a table describing customers with fields for basic contact information such as name, address, phone number, and fax number. Thus, a record in that table may contain a value for each of the fields in the table (e.g., the name in the name field). Another table may describe a purchase order with fields for information such as customer, product, sales price, and date. In various embodiments, standard entity tables, such as tables for account, contact, lead, and opportunity data, are provided for use by all tenants, each containing predefined fields. The MTS700 may store database records for one or more tenants in the same table; that is, tenants may share a table. Thus, in various embodiments, a database record may include a tenant identifier indicating the owner of the database record. As a result, data for one tenant is kept secure and isolated from data for other tenants, so that one tenant cannot access data for another tenant unless the data is explicitly shared.

[0053] In some embodiments, data stored in data storage 712 is organized as part of a log structure merge tree (LSM tree). The LSM tree typically includes two high-level components: an in-memory buffer and persistent storage. During operation, the database server 714 may first write database records to a local in-memory buffer and then flush these records to persistent storage (e.g., data storage 712). As part of flushing database records, the database server 714 may write database records to new files located at the "top" level of the LSM tree. Over time, database records may be overwritten by the database server 714 to new files located at lower levels as the database records move down the LSM tree. In various implementations, as database records become old and move down the LSM tree, they are moved to increasingly slower storage devices in data storage 712 (e.g., from solid-state drives to hard disk drives).

[0054] When database server 714 wants to access a database record for a particular key, database server 714 may traverse different levels of the LSM tree for a file that potentially contains a database record for that particular key. Once database server 714 determines that a file may contain the relevant database record, it may fetch the file from data storage 712 into its own memory. Database server 714 can then check the fetched file for a database record having the particular key. In various embodiments, database records are immutable once written to data storage 712. Therefore, if database server 714 wants to modify the value of a table row (which can be identified from the accessed database record), database server 714 writes a new database record to the top level of the LSM tree. Over time, the database records are merged down the levels of the LSM tree. Thus, the LSM tree can store various database records for a database key, with older database records for that key located at lower levels of the LSM tree than newer database records.

[0055] In various embodiments, the database server 714 is a hardware element, software routine, or combination thereof capable of providing database services such as data storage, data retrieval, and / or data manipulation. The database server 714 may correspond to the database node 120. Such database services may be provided by the database server 714 to components within the MTS 700 (e.g., application server 722) and components outside the MTS 700. As an example, the database server 714 may receive a database transaction request from an application server 722 requesting to write or read data to data storage 712. The database transaction request may specify an SQL SELECT command to select one or more rows from one or more database tables. The content of the rows may be defined in a database record, and therefore the database server 714 may find and return one or more database records corresponding to the selected one or more table rows. In various cases, the database transaction request may instruct the database server 714 to write one or more database records for an LSM tree, and the database server 714 maintains the LSM tree implemented on the database platform 710. In some embodiments, the database server 714 implements a relational database management system (RDMS) or an object-oriented database management system (OODBMS) to facilitate the storage and retrieval of information to and from the data storage 712. In various cases, the database servers 714 may communicate with each other to facilitate the processing of transactions. For example, database server 714A may communicate with database server 714N to determine whether database server 714N has written a database record for a particular key to its in-memory buffer.

[0056] In various embodiments, the application platform 720 is a combination of software routines and hardware elements that implement and run CRM software applications and provide related data, code, forms, web pages, and other information to the user system 750, and store related data, objects, web page content, and other tenant information via the database platform 710. To facilitate these services, in various embodiments, the application platform 720 communicates with the database platform 710 to store, access, and manipulate data. In some cases, the application platform 720 may communicate with the database platform 710 via different network connections. For example, one application server 722 may be connected via a local area network, and another application server 722 may be connected via a direct network link. TCP / IP (Transfer Control Protocol and Internet Protocol) is an exemplary protocol for communication between the application platform 720 and the database platform 710, but it will be apparent to those skilled in the art that other transport protocols may be used depending on the network interconnection used.

[0057] The application server 722 is, in various embodiments, a hardware element, software routine, or a combination thereof capable of providing services to the application platform 720, including processing requests received from tenants of the MTS 700. In various embodiments, the application server 722 may generate environments 724 that can be used for various purposes, such as providing functions for developers to develop, run, and manage applications (e.g., business logic). Data may be transferred to environment 724 from another environment 724 and / or the database platform 710. In some cases, environment 724 cannot access such data unless the data from other environments 724 is explicitly shared. In some embodiments, multiple environments 724 can be associated with a single tenant.

[0058] The application platform 720 may provide the user system 750 with access to multiple different hosted (standard and / or custom) applications, including CRM applications and / or applications developed by tenants. In various embodiments, the application platform 720 may manage application creation, application testing, application storage in database objects in data storage 712, application execution in environment 724 (e.g., virtual machines in process space), or any combination thereof. In some embodiments, the application platform 720 may add and remove application servers 722 from the server pool at any time for any reason, and there may be no server affinity for a particular application server 722 for a user and / or organization. In some embodiments, an interface system (not shown) (e.g., an F5 Big-IP load balancer) implementing load balancing functionality is located between the application server 722 and the user system 750 and configured to allocate requests to the application server 722. In some embodiments, the load balancer routes user requests to the application server 722 using a least connection algorithm. Other examples of load balancing algorithms, such as round robin and observed response time, may also be used. For example, in a particular embodiment, three consecutive requests from the same user may hit three different servers 722, and three requests from different users may hit the same server 722.

[0059] In some embodiments, the MTS 700 provides security mechanisms, such as encryption, to keep each tenant's data separate unless the data is shared. If two or more servers 714 or 722 are used, they may be located in close proximity to each other (e.g., within a server farm located in a single building or campus) or they may be distributed in locations far apart from each other (e.g., one or more servers 714 located in city A and one or more servers 722 located in city B). Thus, the MTS 700 may include one or more logically and / or physically connected servers, either locally or distributed across one or more geographical locations.

[0060] One or more users (for example, via user system 750) may interact with the MTS700 via network 740. User system 750 may represent, for example, a tenant of the MTS700, a provider of the MTS700 (e.g., an administrator), or a third party. Each user system 750 may be a desktop personal computer, workstation, laptop, PDA, mobile phone, or any Wireless Access Protocol (WAP) enabled device, or any other computing device capable of directly or indirectly interfaceing with the Internet or other network connectivity. User system 750 may include dedicated hardware configured to interface with the MTS700 via network 740. The user system 750 may run a graphical user interface (GUI) corresponding to the MTS 700, an HTTP client (such as Microsoft's Internet Explorer® browser, Netscape's Navigator® browser, Opera's browser, or a browsing program such as a WAP-enabled browser in the case of a mobile phone, PDA, or other wireless device), or both, enabling users of the user system 750 (e.g., subscribers to the CRM system) to access, process, and view information and pages available from the MTS 700 via the network 740. Each user system 750 may include one or more user interface devices, such as a keyboard, mouse, touchscreen, or pen, for interacting with the graphical user interface (GUI) provided by a browser on a display monitor screen, LCD display, etc., along with pages, forms, and other information provided by the MTS 700 or other systems or servers. As stated above, the disclosed embodiments are suitable for use on the Internet, which refers to a specific global internet network of the network.However, it should be understood that other networks may be used instead of the internet, such as intranets, extranets, virtual private networks (VPNs), non-TCP / IP based networks, and any LAN or WAN.

[0061] Since users of user system 750 can have different levels of capability, the capabilities of a particular user system 750 can be determined by one or more permission levels associated with the current user. For example, if a salesperson is using a particular user system 750 to interact with MTS700, that user system 750 may have the capabilities assigned to that salesperson (e.g., user privileges). However, if an administrator is using the same user system 750 to interact with MTS700, that user system 750 may have the capabilities assigned to that administrator (e.g., administrative privileges). In a system with a hierarchical role model, a user at one permission level can access applications, data, and database information accessible to users at lower permission levels, but cannot access certain applications, database information, and data accessible to users at higher permission levels. Therefore, different users may have different capabilities regarding accessing and modifying applications and database information, depending on their security or permission level. Some data structures managed by MTS700 are allocated at the tenant level, while others are managed at the user level.

[0062] In some embodiments, the user system 750 and its components can be configured using an application such as a browser, which includes computer code executable on one or more processing elements. Similarly, in some embodiments, the MTS 700 (and any additional instances of the MTS, if there are more than two) and their components can be configured by an operator using an application(s) which include computer code executable on processing elements. Thus, the various operations described herein can be performed by executing program instructions stored on a non-temporary computer-readable medium and executed by the processing elements. Program instructions may be stored on a non-volatile medium such as a hard disk, or, as is well known, on other volatile or non-volatile memory mediums or devices such as ROM or RAM, or provided on any medium from which program code can be initiated, such as a compact disc (CD), a digital versatile disc (DVD), or a floppy disk. Additionally, the entire program code or any part thereof may be transmitted and downloaded from the software source, for example, over the Internet or from another server, as is well known, and may be transmitted, as is well known, over any other conventional network connection (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocol (e.g., TCP / IP, HTTP, HTTPS, Ethernet®, etc.). It will also be understood that computer code for implementing aspects of the disclosed embodiments may be implemented in any programming language that can run on a server or server system, for example, C, C++, HTML, Java, JavaScript®, or any other scripting language such as VBScript.

[0063] Network 740 may be a LAN (Local Area Network), a WAN (Wide Area Network), a wireless network, a point-to-point network, a star network, a token ring network, a hub network, or any other suitable configuration. The global internet of the network is often referred to as the "Internet" with a capital "I" and is an example of a TCP / IP (Transfer Control Protocol and Internet Protocol) network. However, it should be understood that the disclosed embodiments may utilize any of various other types of networks.

[0064] User system 750 may communicate with MTS700 using TCP / IP, and at higher network levels, it may communicate using other common internet protocols such as HTTP, FTP, AFS, and WAP. For example, when HTTP is used, user system 750 may include an HTTP client, commonly called a “browser,” for sending and receiving HTTP messages from the HTTP server on MTS700. Such a server may be implemented as the sole network interface between MTS700 and network 740, although other techniques may be used similarly or instead. In some implementations, the interface between MTS700 and network 740 includes load-sharing features, such as a round-robin HTTP request distributor, to balance the load and distribute incoming HTTP requests evenly across multiple servers.

[0065] In various embodiments, the user system 750 communicates with the application server 722 to request and update system-level and tenant-level data from the MTS 700, which may require one or more queries to the data storage 712. In some embodiments, the MTS 700 automatically generates one or more SQL statements (SQL queries) designed to access the desired information. In some cases, the user system 750 may generate requests having a specific format corresponding to at least a portion of the MTS 700. As an example, the user system 750 may request to move data objects to a specific environment 724 using object notation that describes object relation mappings (e.g., JavaScript® object notation mappings) of a specified set of objects.

[0066] Exemplary computer system Referring now to Figure 8, a block diagram of an exemplary computer system 800 that may implement system 100, database 110, database node 120, MTS 700, and / or user system 750. Computer system 800 includes a processor subsystem 880 coupled to system memory 820 and I / O interface(s) 840 via an interconnect 860 (e.g., a system bus). The I / O interface(s) 840 is coupled to one or more I / O devices 850. For convenience, Figure 8 shows a single computer system 800, but system 800 may be implemented as two or more computer systems working together.

[0067] The processor subsystem 880 may include one or more processors or processing units. In various embodiments of the computer system 800, multiple instances of the processor subsystem 880 may be coupled to the interconnect 860. In various embodiments, the processor subsystem 880 (or each processor unit within 880) may include a cache or other form of onboard memory.

[0068] System memory 820 is available for storing program instructions that can be executed by the processor subsystem 880 in order to cause system 800 to perform various operations described herein. System memory 820 may be implemented using different physical memory media such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (such as RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), and read-only memory (such as PROM, EEPROM, etc.). Memory within computer system 800 is not limited to primary storage such as memory 820. Rather, computer system 800 may also include other forms of storage such as cache memory within the processor subsystem 880 and secondary storage on I / O devices 850 (e.g., hard drives, storage arrays, etc.). In some embodiments, these other forms of storage may also store program instructions that can be executed by the processor subsystem 880. In some embodiments, program instructions that, when executed, implement a database application 130 may be contained in / stored within system memory 820.

[0069] The I / O interface 840 may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, the I / O interface 840 is a bridge chip (e.g., a southbridge) from the front side to one or more back-side buses. The I / O interface 840 may couple to one or more I / O devices 850 via one or more corresponding buses or other interfaces. Examples of I / O devices 850 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs, or their associated controllers), network interface devices (e.g., to a local or wide area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, the computer system 800 is coupled to a network via a network interface device 850 (e.g., configured to communicate via WiFi, Bluetooth®, Ethernet®, etc.).

[0070] The realizations of the subject matter of this application include, but are not limited to, the following examples 1 to 20. <1> It is a method, The computer system receives a metadata document describing the updated schema of a database that stores multiple records, The computer system instantiates a set of processes to execute an upgrade routine to upgrade multiple records to conform to an updated schema, While a set of processes is upgrading multiple records, the computer system The steps include receiving a request to perform an action on one of several records, A step to detect that a record corresponds to a schema version older than the updated schema version in the metadata document, Steps to upgrade records to conform to the updated schema, After upgrading the record, the steps to perform the requested action on the record and A method that includes this. <2> The updated schema describes a set of database entities and a corresponding set of statuses, where the status of the set of statuses indicates whether the corresponding entity can be used to process the request, as in Example 1. <3> Steps include: In response to receiving a status request from a client for the status of a particular database entity from a set of database entities, the computer system returns a response indicating the status of the particular database entity, wherein the client is operable to use the response to determine whether the particular database entity can be used to process the request from the client; The method in Example 2 further includes this. <4> One of the database entities in a set is an index, and the method is, A computer system updates the status of a table on which an index is based within a metadata document, wherein the updated status of the table prevents the table from being deleted while the index is being created. The method in Example 2 further includes this. <5> The updated schema describes indexes that were not described in the previous schema version, and the step of upgrading records to conform to the updated schema is: The steps to add record entries to the index, The steps include: updating the record version to match the updated schema version after inserting entries into the index; and The method in Example 1, including the method described above. <6> The request specifies the minimum schema version that should be used when processing the received request, and the method is: A computer system detects that a schema stored in the computer system's memory does not meet the minimum schema version requirement. The steps include replacing the stored schema with the updated schema in memory and The method of Example 1, further including the above. <7> The updated schema describes a set of updates to a set of database entities, and the first database entity of the set is migrated before the second database entity of the set so that the first database entity is available before the second database entity, as in Example 1. <8> In the method described in Example 1, the record is upgraded and returned to the request issuer without being stored in the database, and the record is then upgraded by one of a set of processes and stored in the database. <9> After a set of processes executes an upgrade routine, the computer system instantiates a set of scrutiny processes to determine whether all of the multiple records have been upgraded to conform to the updated schema. The method of Example 1, further including the above. <10> A non-temporary computer-readable medium that stores program instructions executable by a computer system to cause the computer system to perform an action, wherein the action is: Receiving a metadata document that describes the updated schema of a database that stores multiple records, Instantiating a set of processes to run an upgrade routine to upgrade multiple records to conform to the updated schema, Receiving a request to perform an action on one of several records, Detecting that a record corresponds to a schema version older than the updated schema version in the metadata document, Upgrading records to conform to the updated schema, After upgrading the record, perform the requested action on the record. A medium that includes <11> The request specifies the minimum schema version to be used when processing the received request, and the operation is: To detect when a schema cached in the computer system's in-memory cache does not meet the minimum schema version requirement, Replacing a cached schema with an updated schema within an in-memory cache The medium of Example 10, which further includes the following. <12> The operation is, Receiving another request to perform an action on a different record among multiple records, where the other request does not specify a minimum schema version, and receiving This involves performing a different request operation on different records without upgrading the different records, where the different records correspond to a schema version older than the updated schema version. The medium of Example 10, which further includes the following. <13> Performing the requested action involves removing the upgraded record from the database, as shown in Example 10. <14> The operation is, Maintaining status information that identifies the status of database entities described in the updated schema, In response to upgrading the records associated with a database entity, update the status to indicate that the database entity can be used to process the request. The medium of Example 10, which further includes the following. <15> The operation is, After a set of processes executes an upgrade routine, a set of scrutiny processes is instantiated to determine whether some of the multiple records have been upgraded to conform to the updated schema. The medium of Example 10, which further includes the following. <16> It is a system, At least one processor, A memory containing program instructions that can be executed by at least one process to perform an action on the system. It is equipped with, and its operation is, Receiving a metadata document that describes an updated schema for a database that stores multiple records, Receiving a request to perform an action on one of several records, Detecting that a record corresponds to a schema version older than the updated schema version in the metadata document, Upgrading records to conform to the updated schema, After upgrading the record, perform the requested action on the record. A system that includes this. <17> The request specifies the minimum schema version, and the operation is: Determining that the schema version of the database cached in the system cache is less than the minimum schema version, Within the cache, replace the cached schema with the updated schema. The system in Example 16 further includes the following. <18> The updated schema adds additional fields to the database tables, and the records correspond to the tables; updating the records is possible. Modify the record to include the values ​​of the additional fields, Updating the record version to match the updated schema version and The system in Example 16, including the example. <19> The updated schema describes a set of database entities and a corresponding set of statuses, and its behavior is as follows: Setting the status of one of a set of database entities to indicate that the database entity has been upgraded, and the status is observable by a client capable of issuing database requests to the system. The system in Example 16 further includes the following. <20> The operation is, Instantiating a set of processes to execute upgrade routines to upgrade multiple records to conform to the updated schema. The system in Example 16 further includes the following.

[0071] This disclosure includes references to “embodiments,” which are non-exclusive implementations of the disclosed concepts. References to “embodiments,” “one embodiment,” “a particular embodiment,” “several embodiments,” and “various embodiments” do not necessarily refer to the same embodiment. Numerous possible embodiments are contemplated, including the specific embodiments described in detail, as well as modifications or alternatives that fall within the spirit or scope of this disclosure. Not all embodiments necessarily express any or all of the potential advantages described herein.

[0072] This disclosure may describe the potential benefits that may arise from the disclosed embodiments. Not all implementations of these embodiments necessarily demonstrate any or all of the potential benefits. Whether a benefit is realized for a particular implementation depends on many factors, some of which are outside the scope of this disclosure. In fact, there are several reasons why an implementation included in the claims may not demonstrate some or all of the disclosed benefits. For example, a particular implementation may include other circuits outside the scope of this disclosure that negate or reduce one or more of the disclosed benefits along with one of the disclosed embodiments. Furthermore, suboptimal design execution of a particular implementation (e.g., implementation technique or tool) may also negate or reduce the disclosed benefits. Even assuming a skilled implementation, the realization of benefits may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, the inputs supplied to a particular implementation may prevent one or more of the problems addressed in this disclosure from occurring in certain cases, resulting in the benefits of the solution not being realized. Given the existence of possible external factors, it is expressly intended that any potential benefits described herein should not be construed as limitations on the claims that must be met to demonstrate infringement. Rather, the identification of such potential benefits is intended to illustrate the types(s) of improvements available to designers who have an interest in this disclosure. The permissive description of such benefits (e.g., stating that a particular benefit "may arise") is not intended to convey any doubt as to whether such benefits can actually be realized, but rather to acknowledge the technical reality that the realization of such benefits often depends on additional factors.

[0073] Unless otherwise stated, the embodiments are non-limiting. That is, even if only a single example is described with respect to a particular feature, the disclosed embodiments are not intended to limit the scope of claims drafted based on this disclosure. The disclosed embodiments are intended to be illustrative, not restrictive, and there is nothing to the contrary in this disclosure. Accordingly, this application is intended to enable claims that cover the disclosed embodiments, as well as any alternative forms, modifications, and equivalents that would be obvious to those skilled in the art who are interested in this disclosure.

[0074] For example, the features in this application may be combined in any suitable manner. Therefore, new claims may be formulated for any such combination of features during the examination of this application (or an application claiming priority thereto). In particular, referring to the appended claims, features from dependent claims may be combined, as necessary, with features of other dependent claims, including claims dependent on other independent claims. Similarly, features from each independent claim may be combined, as necessary.

[0075] Accordingly, each of the attached dependent claims may be drafted to depend on a single other claim, but additional dependencies are also contemplated. Any combination of features in the dependent claims that are consistent with this disclosure may be contemplated and claimed in this application or another application. In short, the combinations are not limited to those specifically enumerated in the attached claims.

[0076] Where necessary, a claim drafted in one form or legal type (e.g., apparatus) may also be intended to support a corresponding claim in another form or legal type (e.g., method).

[0077] As this disclosure is a legal document, various terms and expressions may be subject to administrative and judicial interpretation. This specification gives us a notice that the definitions provided in the following paragraphs and throughout this disclosure should be used in determining how to interpret the claims drafted based on this disclosure.

[0078] References to the singular form of an item (i.e., nouns or noun phrases preceded by "a," "an," or "the") are intended to mean "one or more" unless the context explicitly indicates otherwise. Therefore, a reference to "an item" in the claims does not preclude additional instances of that item, unless the accompanying context is present. "Multiple" items refer to a set of two or more items.

[0079] The words “may” are used herein in an impermissible sense (i.e., have the possibility, can do) rather than an impermissible sense (i.e., must).

[0080] The terms "comprising" and "including," as well as their forms, are open-ended and mean "including, but not limited to."

[0081] When the term "or" is used in this disclosure in relation to a list of choices, it will generally be understood to be used in an inclusive sense unless the context otherwise specifies. Thus, the statement "x or y" is equivalent to "x or y, or both," and therefore covers 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, expressions such as "either x or y, but not both" make it clear that "or" is used in an exclusive sense.

[0082] The statements "w, x, y, or z, or any combination thereof" or "...at least one of w, x, y, and z" cover all possibilities, including single elements up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of the set (e.g., w, but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. Thus, the expression "...at least one of w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations in the list of this element. This expression should not be interpreted as requiring the existence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0083] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise specifies, different labels used for features (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Additionally, when the labels “first,” “second,” and “third” are applied to features, they do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise stated.

[0084] The expression "based on" is used to describe one or more factors that influence a decision. This term does not preclude the possibility that additional factors may influence the decision. That is, a decision may be based on the specified factor alone, or on the specified factor and other unspecified factors. Consider the expression "decide A on B." This expression specifies that B is a factor used to determine A or that influences the decision of A. This expression does not preclude the possibility that the decision of A may be based on some other factor, such as C. This expression is also intended to cover embodiments in which A is determined on B alone. As used herein, the expression "based on" is synonymous with the expression "at least in part on."

[0085] The expressions “in response to” and “responsive to” describe one or more factors that cause an effect. These expressions do not preclude the possibility that additional factors, in conjunction with or independently of the specified factors, may influence or otherwise induce the effect. That is, the effect may be in response to these factors alone, or to the specified factors and other unspecified factors. Consider the expression “perform A in response to B.” This expression specifies that B is a factor that triggers the performance of A, or a specific outcome of A. This expression does not preclude the performance of A to occur in response to some other factor, such as C. This expression also does not preclude the performance of A to occur in response to both B and C. This expression is also intended to cover embodiments in which A is performed in response to B alone. As used herein, the expression “in response to” is synonymous with the expression “in response to at least partially to.” Similarly, the expression “in response to” is synonymous with the expression “in response to at least partially to.”

[0086] Within this disclosure, different entities (which may be referred to in various ways, such as “units,” “circuits,” or other components) may be described or claimed as “configured” to perform one or more tasks or operations. This formulation—[entity] configured to perform one or more tasks—is used herein to refer to a structure (i.e., something physical). More specifically, this formulation is used to indicate that this structure is configured to perform one or more tasks while in operation. A structure can be said to be “configured” to perform some task even if that structure is not currently in operation. Thus, entities described or enumerated as “configured” to perform some task refer to something physical, such as a device, a circuit, or a system having memory and a processor unit that stores executable program instructions to perform a task. This expression is not used herein to refer to anything intangible.

[0087] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It is understood that these entities, even if not specifically mentioned, are "configured to" perform those tasks / operations.

[0088] The term "configured" does not mean "configurable." For example, an unprogrammed FPGA is not considered "configured to" perform a particular function. However, this unprogrammed FPGA may be "configurable" to perform that function. After proper programming, an FPGA can be said to be "configured" to perform a particular function.

[0089] For the purposes of a U.S. patent application based on this disclosure, any claim statement that a structure is “configured to perform one or more tasks” is expressly intended not to enforce Section 112(f) of the U.S. Patent Act with respect to the elements of that claim. If the applicant wishes to enforce Section 112(f) during the examination of a U.S. patent application based on this disclosure, the applicant should enumerate the elements of the claim using “means for” configurations [to perform a function].

Claims

1. A method that a computer system can perform, A step of receiving a metadata document describing an updated schema of a database that stores multiple records, wherein the updated schema describes a set of database entities and a corresponding set of statuses, the status of the set of statuses indicating whether the corresponding database entity can be used to process a request. Steps include instantiating a set of processes for executing an upgrade routine to upgrade the plurality of records to conform to the updated schema, The steps include receiving a request to perform an action on one of the records while the set of processes is upgrading the multiple records, The steps include: detecting whether one of the records corresponds to an earlier schema version than the updated schema version of the metadata document while the set of processes is upgrading the multiple records; In response to the detection result that the one record corresponds to a schema version earlier than the updated schema version of the metadata document, the steps include upgrading the one record to conform to the updated schema before performing the action of the request on the one record, The steps include: upgrading the aforementioned record, and then performing the operation of the request for the aforementioned record; Steps include: In response to receiving a status request from a client for the status of a particular database entity from the set of database entities, the computer system returns a response indicating the status of the particular database entity, wherein the client is operable to use the response to determine whether the particular database entity can be used to process the request from the client; A method that includes this.

2. One of the aforementioned set of database entities is an index, and the method is A step in which the metadata document updates the status of the table on which the index is based, wherein the updated status of the table prevents the table from being deleted while the index is being created. The method according to claim 1, further comprising:

3. The updated schema describes indexes not described in the previous schema version, and the step of upgrading the single record to conform to the updated schema is: The steps include: inserting the entry of the aforementioned record into the index; The steps include: after inserting the entry into the index, updating the version of the one record to match the version of the updated schema; The method according to claim 1, including the method described in claim 1.

4. The request that performs the aforementioned operation specifies the minimum schema version to be used when processing the received request, and the method A step of detecting whether the schema stored in the memory of the computer system satisfies the minimum schema version, In response to a detection result indicating that the schema stored in the memory of the computer system does not meet the minimum schema version, the steps include replacing the stored schema in the memory with the updated schema. The method according to claim 1, further comprising:

5. The method according to claim 1, wherein the updated schema describes a set of updates to a set of database entities, and the first database entity of the set of database entities is migrated before the second database entity of the set of database entities so that the first database entity is available before the second database entity.

6. The method according to claim 1, wherein the one record is upgraded and returned to the issuer of the request without being stored in the database.

7. The step of instantiating a set of review processes to determine whether all of the multiple records have been upgraded to conform to the updated schema after the upgrade routine performed by the set of processes described above. The method according to claim 1, further comprising:

8. A computer system, At least one processor, A memory storing a program that causes at least one processor to execute the method according to any one of claims 1 to 7, A computer system equipped with the following features.

9. A computer-readable storage medium storing a program for causing a computer system to perform a processing operation, wherein the processing operation is: Receiving a metadata document describing an updated schema of a database storing multiple records, wherein the updated schema describes a set of database entities and a corresponding set of statuses, the status of the set of statuses indicating whether the corresponding database entity can be used to process a request. Instantiating a set of processes for executing an upgrade routine to upgrade the multiple records to conform to the updated schema, While the aforementioned set of processes is upgrading the multiple records, a request is received to perform an action on one of the multiple records, While the set of processes is upgrading the multiple records, it is detected whether one of the records corresponds to a schema version earlier than the updated schema version of the metadata document. In response to the detection result that the one record corresponds to a schema version earlier than the updated schema version of the metadata document, the one record is upgraded to conform to the updated schema before performing the action of the request on the one record, After upgrading the aforementioned record, the aforementioned action of the request is performed on the aforementioned record, In response to receiving a status request from a client for the status of a specific database entity among the set of database entities, the system returns a response indicating the status of the specific database entity, causing the client to determine that the specific database entity can be used to process the request from the client. Computer-readable storage media including [unclear text].

10. The request that performs the aforementioned operation specifies the minimum schema version to be used when processing the received request, and the processing operation is The process involves detecting whether the schema cached in the in-memory cache of the computer system satisfies the minimum schema version, In response to a detection result indicating that the schema cached in the in-memory cache of the computer system does not meet the minimum schema version requirement, the cached schema is replaced with the updated schema within the in-memory cache. The computer-readable storage medium according to claim 9, further comprising:

11. The aforementioned processing operation is, Receiving another request to perform an action on one different record among the aforementioned multiple records, wherein the other request does not specify a minimum schema version, and receiving Performing the actions of the other request on the other record without upgrading the other record, wherein the other record corresponds to a schema version prior to the updated schema version. A computer-readable storage medium according to claim 9 or 10, further comprising:

12. The computer-readable storage medium according to claim 9, wherein performing the operation of the request includes deleting the upgraded record from the database.

13. The aforementioned processing operation is, Maintaining status information that identifies the status of database entities described in the updated schema, In response to upgrading the records associated with the aforementioned database entity, update the status to indicate that the aforementioned database entity can be used to process the request. The computer-readable storage medium according to claim 9, further comprising:

Images