inferring encapsulation and intra-module dependencies

Abstract

Here are dependency detection tools and discovery techniques for a mixed language database management system (DBMS). In an embodiment, a client bundler extracts metadata specifying dependencies of a guest module from source file(s) that are part of the guest module. An introspection function is produced that returns the metadata. A database call specification is produced for the introspection function. The (e.g., same) client program sends to the DBMS: the source file(s) that are part of the guest module, the dependency metadata, the introspection function, and the database call specification. In an embodiment, the DBMS extracts metadata describing dependencies of guest module(s) defined in a guest programming language(s) in the DBMS. A report of dependencies is produced based on the metadata describing the dependencies. Based on the report, the DBMS can identify a subset of dependencies on which a particular guest module(s) depends.

Description

Technical Field

[0001] This invention relates to hybrid language programming for databases. The technique described here is to extend a database management system (DBMS) to automatically discover and report a hierarchical system of dependencies used by guest modules of a guest programming language implemented within the DBMS. Background Technology

[0002] Data persistence can take various logical forms. Transactional workloads (OLTP) are supported by data models that are slightly different from those used in analytical workloads (OLAP). Document and multimedia data rely on various formats, such as JavaScript Object Notation (JSON) and Extensible Markup Language (XML). The concept that different database models are better suited to address the needs of different applications is called hybrid language persistence.

[0003] One way to address these mixed-language requirements is to have separate offerings that implement specific database models to solve specific applications. Examples of this include Oracle offerings such as BerkeleyDB as a key-value store, Oracle NoSQL databases as key-value and sharded databases, Oracle TimesTen as a database in storage, and Essbase for analytical processing.

[0004] Various open-source and proprietary products are available to support single-model hybrid language persistence schemes. As commercial enterprise relational databases have evolved over time, they have incorporated multiple data models and access methods within a single database management system. This concept is known as multi-model hybrid language persistence, and it allows many applications to use the same database management system while continuing to benefit from the unique data models required by specific applications.

[0005] Modern programming languages ​​(such as JavaScript and Python) benefit from a rich and vast ecosystem of publicly available libraries and add-ons. However, even hybrid language database systems lack universal support for the Software Development Lifecycle (SDLC) with multiple programming languages. For example, for JavaScript and Python, encapsulation management and encapsulation imports have inconsistent schemes that can be difficult or impossible to reconcile. There is no clear and consistent way to discover within a database management system (DBMS) which guest language software components depend on which other guest language software components. Attached Figure Description

[0006] In the attached diagram:

[0007] Figure 1This is a block diagram describing an exemplary database management system (DBMS) that generates a report based on metadata extracted from the visitor modules in order to identify the dependencies of a specific visitor module among many visitor modules.

[0008] Figure 2 This is a flowchart describing an exemplary computer process for generating a report on dependencies based on metadata extracted from a visitor module in a DBMS, such as in order to identify the dependencies of a specific visitor module.

[0009] Figure 3 This is a block diagram describing an exemplary DBMS that extracts dependency metadata from a visitor module in a language-neutral format, aggregated by database table functions that support database views, which can be probed to discover module dependencies.

[0010] Figure 4 This is a flowchart describing an exemplary DBMS process for extracting dependency metadata aggregated by database table functions that support database views from a visitor module in a language-neutral format. The database views can be probed to discover module dependencies, such as for identifying dependencies of a particular visitor module.

[0011] Figure 5 This is a block diagram describing an exemplary client program configured for a guest module that performs dependency discovery by a DBMS.

[0012] Figure 6 This is a flowchart describing the client-side processing used to configure the visitor module for dependency discovery performed by the DBMS;

[0013] Figure 7 The table results of an exemplary MLE_MODULE_INTROSPECTION_VIEW selection query for an exemplary deployment of module A and module B are described.

[0014] Figure 8 The table results of an exemplary MLE_MODULE_CONTENT_HIERARCHY_VIEW selection query for an exemplary deployment of module A and module B are described.

[0015] Figure 9 This is a block diagram illustrating a computer system that can implement embodiments of the present invention;

[0016] Figure 10 It is a block diagram representing the basic software system that can be used to control the operation of a computing system. Detailed Implementation

[0017] In the following description, numerous specific details are set forth for illustrative purposes in order to provide a thorough understanding of the invention. However, it will be clear that the invention can be practiced without these specific details. In other instances, well-known structures and devices are illustrated in block diagram form to avoid unnecessarily obscuring the invention.

[0018] Overview

[0019] Here is the technology: extending a hybrid language database management system (DBMS) to automatically discover and report the hierarchy of dependencies used by guest modules in a guest programming language implemented within the DBMS. An introspection instrumentation tool, including metadata about the dependency hierarchy, is generated and manipulated to reveal the interdependencies of guest modules. Without this encapsulated introspection technology, there is no clear and uniform way to discover which software components a guest module includes. For example, a DBMS might have a privileged model that allows users to deploy guest language code without administrator privileges, which exacerbates the need for guest module introspection. For instance, there might be a requirement for a database administrator (DBA) who is not the developer of the guest module to be able to detect which versions of which open-source software components (such as libraries) the guest module includes.

[0020] In this embodiment, introspection information is inserted into the visitor module as a nested data type, such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML). The introspection information is exported via a language-specific export mechanism, which, for JavaScript or Python, may be a function that returns a nested data type.

[0021] The technology here enables module introspection information to be displayed as a database view. By querying this view, users are provided with detailed module encapsulation information in a normalized form. As discussed later here, document query languages ​​(such as JSON query) can be used to remove nesting of any nested data types and extract the contained data in a normalized form. This query language construction facilitates one or more database views(s) that extract dependency metadata and organize the dependency metadata in hierarchical and / or tabular form. For example, a DBMS can collect a list of deployed guest modules from one or more database views(s).

[0022] The auxiliary tools provided here are responsible for bundling and deploying guest modules for each guest language. The auxiliary tools collect bundling information and add it to the guest module source code, such as dependency metadata and introspection functions. For each guest module, such as when it is deployed, they generate database call specifications using reserved names. This task is performed by the auxiliary tools for the guest language. By integrating dependency introspection detection tools into the auxiliary deployment tools, this approach provides an automated way to collect dependency metadata and include it directly within each deployed guest module.

[0023] In one embodiment, the client bundler extracts metadata about the dependencies of a specified guest module from one or more source files that are part of the guest module. An introspection function is generated, which returns the metadata about the specified dependencies. A database call specification is generated for the introspection function. The same or different client programs send the following to the DBMS: the one or more source files that are part of the guest module, the metadata about the specified dependencies, the introspection function, and the database call specification for the introspection function.

[0024] In an embodiment, the DBMS extracts metadata describing the dependencies of one or more visitor modules defined in one or more visitor programming languages ​​implemented in the DBMS. A dependency report based on the metadata describing the dependencies is generated. The DBMS can then identify a subset of dependencies that a particular visitor module depends on based on the dependency report.

[0025] 1.0 Exemplary Computer System

[0026] Figure 1 This is a block diagram illustrating an exemplary database management system (DBMS) 100 in an embodiment. To identify dependencies among a plurality of guest modules, DBMS 100 generates a dependency report based on metadata extracted from the guest modules. DBMS 100 includes and is hosted by one or more computers (not shown), each of which may be a rack server (such as a blade server), a personal computer, a mainframe computer, a virtual computer, or other computing device. When DBMS 100 includes multiple computers, the computers are interconnected via a communication network.

[0027] According to the technology disclosed in relevant U.S. Patent Application 16 / 556,760, DBMS 100 supports hybrid language (i.e., multilingual) programmable databases, such as Oracle's Graal MLE, which has a multilingual engine (MLE) software layer. For multiple guest programming languages, the MLE software layer can be embedded individually or as a combination of interpreters and / or virtual machines, such as a Java Virtual Machine (JVM) or a JavaScript interpreter. For example, the MLE can interpret text scripts, generate bytecode, interpret bytecode, and / or compile the bytecode into native machine instructions, such as through just-in-time (JIT) compilation. The MLE may include a JVM that executes bytecode generated from source logic in multiple guest programming languages ​​111-112.

[0028] According to the technology disclosed in related U.S. Patent Application 16 / 556,760, a new guest programming language can be added to DBMS 100 more or less as a plug-in, extending DBMS 100 to give it new capabilities, such as interpreting or otherwise executing logic written in said new guest programming language. For example, DBMS 100 may initially be provided as middleware from an Original Equipment Manufacturer (OEM) or Independent Software Vendor (ISV) without supporting any particular guest programming language. After DBMS 100 is deployed, support for one or more specific new guest programming languages ​​may be added to DBMS 100 as an aftermarket extension. For example, DBMS 100 may be future-proofed because it is designed to include implementations of new guest programming languages ​​that were not present when DBMS 100 was initially deployed.

[0029] Each visitor module (e.g., 121-123) is a management and / or lexical (i.e., scope / visibility) unit that defines one or more visitor objects (not shown), such as subroutines, which are native to the visitor programming language (e.g., 111-112) and accessible from outside the visitor module (e.g., public access). According to an embodiment, visitor module 121 may contain other objects that: a) are also publicly accessible but are not subroutines, such as global variables, such as data structures; b) are accessible only from within visitor module 121; or c) are accessible only from within visitor programming language 111.

[0030] In this embodiment, the guest module 121 can be created for a guest programming language 111, such as that presented here and in related application 16 / 556,760, by executing data definition language (DDL) statements in the DBMS 100. When created, the guest module 121 can be registered within a database schema (not shown), such as a schema explicitly named in the DDL statements, or registered within a default schema, such as the current, global, and / or system schema. Because schemas serve as namespaces, modules in different schemas can have the same unqualified name but different name qualifiers.

[0031] In one example, the DDL statement creating visitor module 121 contains source logic of visitor programming language 111, which DBMS 100 executes to create visitor module 121. In another example, the DDL statement references a script file of visitor programming language 111, which DBMS 100 executes to create visitor module 121. In yet another example, the DDL statement references a large object (LOB), such as a character LOB (CLOB) or a binary LOB (BLOB), which is stored as a field value in a row of a database table in DBMS 100.

[0032] As explained above, visitor module 121 may define one or more visitor objects, such as visitor subroutines, which are exposed and can be used by: other visitor modules (such as 122) in the same visitor programming language 111, visitor modules (such as 123) in other visitor programming languages ​​(such as 112), and the native data manipulation language (DML) (such as Structured Query Language (SQL)) of DBMS 100.

[0033] DML stands for Domain-Specific Language (DSL), and its domain is the database content. DML is designed to access the content structure within a database, including relational keys, such as tables, records, and fields. DML is native to DBMS 100 because DBMS 100 was originally designed to interpret or otherwise execute DML. For example, DBMS 100 may have a query planner that heavily relies on aspects of DML. However, the query planner is unaware of aspects that distinguish guest programming languages, such as their syntax, semantics, and data types.

[0034] DBMS 100 can execute DML statements (not shown) that call guest programming languages ​​111 and / or 112 in DBMS 110, such as database queries. For example, as presented here later, a database administrator (DBA) can export subroutines of guest programming language 140 as user-defined functions (UDFs) or stored procedures that can be called by DML statements.

[0035] For example, a DML statement can be a query. Therefore, the guest programming language 111 can be used indirectly for DML queries without exposing the client to the guest programming language 111. For example, a traditional query can invoke a complex UDF that was originally implemented as suboptimal DML and is eventually transparently revamped (e.g., reimplemented and accelerated) by the guest programming language 111.

[0036] Each of the visitor modules 121-123 is an exportable (i.e., public) and importable (i.e., usable) visitor object. The visitor module (such as 121) may depend on various dependencies (such as 141-142) that are not exported by the visitor module but are instead implemented as software libraries (such as third-party libraries and / or archive files) that can be linked to the visitor module 121.

[0037] Similarly, multiple guest modules (such as 121-122) may require dependencies such as 142. Guest modules 121 and 123, defined in different guest programming languages ​​111-112, may require dependencies such as 141.

[0038] In any case, depending on the guest module's implementation in whichever guest programming language it may be based, each of the guest modules 121-123 provides metadata 131-133 for identifying the required dependencies(s) 141-143. In an embodiment, each of the guest modules 121-123 provides a guest function in its respective guest programming language, which the DBMS 100 can invoke to extract metadata (such as 131-133) from the catalog of the required dependencies(s). Dependencies and dependency metadata extraction will be discussed later here.

[0039] Therefore, through introspection of metadata 131, DBMS 100 can discover that visitor module 121 depends on dependencies 141-142. After extracting metadata 131-133, DBMS 100 can generate reports (not shown) (e.g., for immediate use or stored for later use) or summarize other aggregations of metadata 131-133 in a manner that reveals which visitor modules in visitor modules 121-123 depend on which dependencies 141-143. An exemplary dependency report is presented here later.

[0040] Various embodiments may provide a dependency report that includes various combinations of the following exemplary content for each dependency of one, some, or all of the visitor modules:

[0041] ● The name of the dependency.

[0042] ● The version number or release date of the dependency.

[0043] ● The name of at least one guest module that depends on the dependency.

[0044] ● The name of at least one other dependency that depends on the dependency.

[0045] ● The name of at least one other dependency that the dependency depends on.

[0046] ● Define the name of at least one database schema that defines the dependency.

[0047] ●Integrity value,

[0048] ● A generic resource identifier (URI) that identifies the implementation of dependencies.

[0049] ● The timestamp when the implementation of the dependency is included in the DBMS.

[0050] ● Include dependencies in the identifiers of database users or database roles in the DBMS, and / or

[0051] ● Indicates whether the dependency is only used for development tags.

[0052] Integrity values ​​can be checksums, such as Cyclic Redundancy Check (CRC) codes or other hash codes, which can be calculated from the guest module's codebase to detect whether the guest module's codebase has been tampered with. For example, a guest module can be implemented as a library distributing an archive file with an original integrity value calculated by an independent software vendor (ISV) or other author based on the archive file. For example, a URI (such as a Universal Resource Locator (URL)) can be used to retrieve the original archive file and / or the original integrity value. Dependency reports can indicate whether the original integrity value matches the following integrity values: a) the integrity value of the archive file when it was deployed to DBMS 100, such as during the deployment of the guest module, and / or b) the integrity value of the archive file currently stored for DBMS 100.

[0053] In some cases, the guest module requires specific dependencies for development purposes only, rather than production use. For example, dependency 143 may include tool extensions, such as plugins for an integrated development environment (IDE) or test suites for test cases used for unit testing. Metadata 132 may contain tags indicating that the guest module 122 requires dependency 143 only for development purposes.

[0054] 2.0 Exemplary Dependency Discovery and Reporting Processing

[0055] Figure 2This is a flowchart describing an exemplary process for generating a report on dependencies based on metadata extracted from a visitor module in a DBMS, such as to identify the dependencies of a specific visitor module. (Refer to...) Figure 1 discuss Figure 2 .

[0056] The timing of steps 202, 204, and 206 depends on the scenario. In one scenario, those steps can occur immediately when guest module 121 is deployed to DBMS 100. In another scenario, those steps occur later on demand, such as auditing dependencies for one or more specific guest modules or all guest modules in DBMS 100. Details on initiation will be presented here later. Figure 3 An example database command for processing.

[0057] Step 202 extracts metadata (such as 131-133) describing the dependencies (such as 141-143) of one or more visitor modules 121-123 defined in one or more visitor programming languages ​​111-112 in DBMS 100. For example, if the scenario requires the deployment of a specific visitor module 121, the embodiment may limit the metadata extraction to metadata 131 describing some dependencies 141-142. If the scenario alternatively requires a full audit of all visitor modules 121-123, the extraction includes all metadata 131-133 describing all dependencies 141-143.

[0058] Step 204 generates a dependency report based on the metadata describing the dependencies. For example, the metadata extracted during step 202 can be used to generate a dependency report in tabular form. The normalization of the tabular data may depend on the implementation and / or scenario.

[0059] For example, each line in the report may have a semantic scope that includes one dependency of a visitor module, all dependencies of a visitor module, or all visitor modules that include the same dependency. Each line in the report may be stored as a row in a database table and / or printed as a line item in a text report (such as a spreadsheet). Mechanisms for metadata extraction, parsing, and normalization will be presented later here.

[0060] The execution or omission of step 206 depends on the scenario. In a comprehensive audit of all guest modules or the deployment of a single guest module, the dependency report generated by step 204 may be sufficient. However, as explained later here, dependency reports can be generated by DML statements such as those using table functions, and / or dependency reports can be logged as rows in a database table.

[0061] Therefore, step 206 may utilize DML statements to apply projection, classification, grouping, and / or filtering to identify or, in a particular way, organize the list of dependencies and visitor modules. For example, step 206 may identify: a) which visitor modules are affected by the same obsolete (i.e., outdated) or buggy (i.e., defective) version of a particular dependency, b) which visitor modules depend on any version (e.g., within a specific range of versions) of a particular third-party library, such as when migrating those visitor modules to the same latest version, c) which visitor modules depend on incompatible versions of two dependencies, and / or d) which dependencies have tampered implementations.

[0062] Therefore, even when an implementation may not require actual sharing of codebase files between guest modules, such as when each guest module should have a copy of the same version of its dependencies, developers or DBAs can still have more or less customized and uniform visibility into relevant parts of the combined codebase of all guest modules. For example, in a multi-tenant DBMS, such as in an enterprise's private cloud, the diversity of dependencies and versions and their copies may be more or less difficult to review without performing step 206.

[0063] 3.0 Introspection Detection Tool

[0064] Figure 3 This is a block diagram illustrating an exemplary DBMS 300 in an embodiment. DBMS 300 extracts dependency metadata from the visitor module in a language-neutral format, aggregated by database table functions supporting database views that can be probed to discover module dependencies. DBMS 300 may be an implementation of DBMS 100.

[0065] Within DBMS 300, the visitor module 320 is implemented in the visitor programming language 310. The visitor module 320 has metadata 341, which indicates that the visitor module 320 requires dependencies 380. The visitor module 320 and other visitor modules (not shown) may depend on other dependencies (not shown), as indicated by various metadata (such as 342).

[0066] Database view 350 is defined in DBMS 300 to provide access to dependency information stored in metadata (such as 341-342). Unlike typical database views, which are supported by one or more ordinary database tables, database view 350 is instead supported by table functions 390. For example, all database views 350, table functions 390, guest modules 320, and calling specifications 360 may be individually defined in the database schema and / or database dictionary.

[0067] Unlike ordinary database functions that return scalar values, table function 390 returns an object containing tabular data organized as a collection of rows and columns, which DBMS 300 can use as if the returned object were a database table or row set that would be returned by a subquery. In this embodiment, table function 390 is a built-in function within DBMS 300 that transforms and aggregates metadata 341-342 into a tabular form. In this embodiment, metadata 341 is initially formatted as a well-formed, independent, and / or hierarchical data structure, shown as document 370, which is encoded according to JavaScript Object Notation (JSON), but the guest programming language 310 does not need to be JavaScript. In this embodiment, metadata 341 (i.e., document 370) is encoded in Extensible Markup Language (XML).

[0068] Metadata 341 can be generated on demand by invoking the introspection function 330 of the visitor object contained in visitor module 320. As explained earlier here, visitor module 320 is created by executing a DDL statement. In an embodiment, the DDL statement contains the name and / or signature of the introspection function 330, which is ultimately called by DBMS 300 to extract dependency metadata 341. In an embodiment, the name and signature of the introspection function 330 are implied (i.e., reserved) by the naming convention of the dependency metadata factory functions that can be invoked by DBMS 300. For example, each visitor module in all visitor programming languages ​​in DBMS 300 may contain a visitor function with the same name and signature as expected by DBMS 300. Those expected visitor functions do not interfere with each other, and there are no signature or name conflicts because DBMS 300 provides a separate namespace for each visitor module.

[0069] The DDL statement that creates the visitor module 320, or subsequent DDL statements, creates a calling specification 360, which facilitates the introspection function 330 from the DML. Typically, the call parameters and return type of the introspection function 330 are reflected in the calling specification 360. Therefore, metadata 341 can be accessed by DML that directly invokes the calling specification 360, which in turn triggers a call to the introspection function 330 that returns metadata 341.

[0070] In this embodiment, the introspection function 330 and / or the invocation specification 360 are generated automatically. For example, one or more DDL statements that create the introspection function 330 and / or the invocation specification 360 may be generated automatically. In this embodiment, such automatic generation may be more or less integrated into a bundling tool that prepares the guest module for loading into the DBMS 300. For example, the guest module 320 may be based on a custom Python script that depends on some third-party Python libraries, which may be used as native Python modules and / or Python wrappers not installed in the DBMS 300.

[0071] DBMS 300 provides a bundling tool (not shown) that analyzes a custom Python script, its import statements, and / or library load paths to detect which versions of Python libraries the script depends on. For example, the bundling tool may operate more or less as a static linker on a developer's or other customer's computer, assembling the script and its libraries into a bundle (not shown) that can be uploaded and deployed to DBMS 300 as a unit. The operation of the bundling tool requires static resolution of dependencies (such as imports) to identify specific versions of specific libraries that satisfy the dependencies.

[0072] Bundling tools can identify and / or retrieve libraries(s) in the local file system and / or on the global Internet, for example, via URL. During operation, the bundling tool naturally accumulates most or all of the information required to generate or otherwise configure the introspection function 330, metadata 341, and calling specification 360. In this embodiment, only the custom Python script is handwritten, and the bundling tool automatically generates the bundle, introspection function 330, calling specification 360, and one or more DDL statements(s) discussed in a DDL script (not shown). In this way, the bundle for the guest module 320 is ready to be deployed to the DBMS 300 in a more or less turn-key manner. The bundling tool for the DBMS 300 can also use artifacts generated by best-of-breed third-party bundling tools for specific guest programming languages, as discussed later here.

[0073] As explained above, a call to table function 390 can convert a hierarchical data object (such as a JSON document 370) into tabular data. In this embodiment, table function 390 is a built-in function of DBMS 300 that converts JSON into relational data, such as the JSON_TABLE function of the SQL / JSON standard 2016. An exemplary call to JSON_TABLE will be presented here later.

[0074] In this embodiment, call specification 360 is invoked repeatedly, once for each visitor module, to obtain multiple metadata (such as 341-342). In this embodiment, each metadata in metadata 341-342 is returned from introspection function 330 as an internal JSON document (such as 370). In this embodiment, table function 390 (such as JSON_TABLE) is invoked repeatedly, once for each JSON document, to obtain multiple table rows declaring the dependencies of the visitor modules. Exemplary fields in such rows will be presented here later.

[0075] 4.0 Exemplary Introspection Processing

[0076] Figure 4 This is a flowchart describing an exemplary process for extracting dependency metadata aggregated by database table functions supporting a database view from a visitor module in a language-neutral format. The database view can be probed to discover module dependencies, such as for identifying dependencies of a particular visitor module(s). (See also...) Figure 3 discuss Figure 4 .

[0077] Step 402 is preparatory. As explained later here, client programs may automatically generate database call specifications for each introspection function for each guest module, such as during deployment bundle generation. In an embodiment, DBMS 300 accepts guest modules that lack some introspection detection tools (such as introspection functions or their call specifications). In this case, step 402 automatically generates those missing parts, which may occur urgently when guest modules are defined (i.e., deployed) in DBMS 300.

[0078] In addition to this deployment-time behavior, step 402 also invokes the database invocation specification in each of the visitor modules in one, some, or all of the visitor modules in DBMS 300. The invocation of the invocation specification (one or more) may occur urgently during deployment or later on demand. Retrieving dependency metadata from the visitor modules (one or more) is the reason for the (one or more) invocations, which requires step 404a as follows.

[0079] Step 404a extracts metadata describing the dependencies of one or more visitor modules. Step 404a may require performing some or all of the steps in steps 404b-h using a specific metadata extraction technique. Some embodiments may combine some steps 404b-h as the same operation. For example, step 404b calls one or more visitor programming languages ​​to extract dependency metadata. Similarly, step 404c calls the introspection functions in each visitor module to extract dependency metadata. Because each introspection function is implemented in the visitor programming language, steps 404b-c will be combined. Embodiments may have combinations of the same or other steps 404b-h.

[0080] Steps 404d, f, and g directly process the JSON or XML encoded with dependency metadata as follows. Step 404d extracts the JSON or XML from each visitor module. For example, each visitor module may provide JSON or XML as a global variable or function return value. An example JSON is presented here later. Step 404f converts the JSON or XML into tabular data. For example, the standard SQL JSON_TABLE function tabulates the JSON data, as illustrated here later.

[0081] Step 404g-h involves calling table functions in DML to aggregate data. For example, step 404h aggregates different JSON or XML documents obtained from different sources. Step 404g aggregates dependency metadata from each visitor module.

[0082] One dependency may depend on another dependency, in which case the dependency metadata can be hierarchical. Step 404e extracts the hierarchical metadata either holistically or in segments to obtain metadata for transitive closures of interdependent relationships for the visitor module. Whether the hierarchical metadata is extracted holistically or in segments depends on the implementation.

[0083] In the exemplary embodiments presented here later, the metadata hierarchy does not directly reflect a tree of interdependent relationships. Instead, it encodes those dependencies as flattened layers within the metadata hierarchy, such as JSON arrays, and the dependency tree can be reconstructed after the flattened layers are extracted. For example, metadata for one dependency can be cross-referenced by dependency name to metadata elsewhere in the flattened layer for another dependency, as shown later here. Thus, if flattened, a dependency hierarchy of arbitrary depth can be extracted without recursion, such as without recursive DML queries and recursive function calls. When both the first and second dependencies depend on the same third dependency, the metadata hierarchy is not a tree, but rather a directed acyclic graph (DAG) that is also well-suited for flattening.

[0084] Step 406a uses a database view based on dependency metadata, which can occur in various scenarios. For example, each step in steps 406b-c can be used for a separate scenario or the same scenario. Step 406b generates a report of dependencies from the database view. Step 406c uses filtering, such as in DML, to identify specific dependencies (one or more) of interest and / or (one or more) visitor modules, as discussed earlier here.

[0085] 5.0 Module bundling executed by the client

[0086] Figure 5 This is a block diagram illustrating an exemplary client-server system 500 in an embodiment. The client configures a guest module for dependency discovery performed by a DBMS 570. DBMS 570 may be an implementation of DBMS 100.

[0087] The client-server system 500 includes a client (not shown) and a DBMS 570. In one embodiment, the client is a local client hosted on the same computer (not shown) as the DBMS 570. In another embodiment, the client is a remote client that interoperates with the DBMS 570 using a communication network (not shown). In either case, the client can be a software program that includes a database driver, such as one that interoperates with the DBMS 570 using Open Database Connectivity (ODBC).

[0088] To ensure that DBMS 570 can easily discover the dependencies of Guest Module 510, the client should configure Guest Module 510 to include introspection detection tools as follows. The codebase artifacts of Guest Module 510 may contain one or more source files, such as 520. For example, source file 520 may be a script written in the guest programming language of DBMS 570 (such as Python, JavaScript, or Ruby).

[0089] Source file 520 may include dependencies, such as 541-543, by reference. For example, source file 520 may contain instructions for importing dependency 541, which may resolve to an instance of or a component of an instance of a script file, a library (i.e., an archive) file, or a directory or directory tree in a file system.

[0090] A hierarchical system of dependencies may exist. For example, dependency 541 may be a third-party library for digital signatures that depends on dependency 543, and dependency 543 may be a third-party library for cryptography. In this embodiment, source file 520 only explicitly references top-level dependencies 541-542, without referencing their transitive overriding (i.e., dependencies of dependencies, such as 543).

[0091] In an embodiment, a tool or person creates a project configuration file that catalogs the dependencies 541-543 of the visitor module 510. For example, a tool (such as Webpack or NPM for JavaScript or Pip for Python) may generate a dependency metadata file, which a client may automatically transform into metadata 530. Such a tool and / or client may aggregate various deliverable artifacts into a single bundle (i.e., archive) file, such as one or more source files 520, statically resolved dependencies 541-543, and an introspection tool that may include the project configuration file, metadata 530, introspection functions 550, and / or database call specifications 560.

[0092] Introspection function 550 and database call specification 560 can be Figure 3 The client can automatically generate the introspection function 550 and the database call specification 560 before or after the generation of metadata 530, with each implementation of the introspection function 530 and the call specification 560 respectively. For example, metadata 530 may be a unique part of the introspection detection tool that is unique to the visitor module 510. For example, introspection function 550 and / or database call specification 560 may be copied to different visitor modules using the same visitor programming language as visitor module 510.

[0093] After automatically configuring the visitor module 510 into a deliverable bundle, the client can deploy the bundle to the DBMS 570, either as an initial deployment or as an upgrade (i.e., replacement) of an earlier version of the visitor module 510 already deployed to the DBMS 570. In embodiments, deployment may require the client to automatically send the bundle to the DBMS 570, such as via sockets for network communication or sockets for inter-process communication (IPC) using transport protocols such as Hypertext Transfer Protocol (HTTP).

[0094] In one embodiment, the client sends a locator, such as a file system path or URL, to the DBMS 570, which the DBMS 570 can use to automatically retrieve the bundle. For example, the client may send a DDL statement defining the guest module 510 in the DBMS 570. This DDL statement may contain a locator for the bundled file. In another embodiment, the client or its user provides (e.g., uploads) the bundled file to the DBMS 570's file system before sending the DDL statement locating the bundled file.

[0095] DBMS 570 can invoke the introspection detection tools of the bundled file immediately or later as needed to generate a report of dependencies 541-543 for the visitor module 510. Some or all dependencies may have been statically linked to the bundled file when it was generated. In this embodiment, all dependencies should be statically linked.

[0096] In this embodiment, other dependencies are cataloged in metadata 530 but not bundled. In this case, such as when DBMS 570 already has an implementation of a missing dependency, DBMS 570 can resolve those missing dependencies eagerly or lazily via dynamic linking. For example, a different visitor module using the same visitor programming language as visitor module 510 may already have an implementation of a missing dependency that can be shared with visitor module 510. Similarly, DBMS 570 can use a locator (such as a URL) to retrieve missing dependencies from a codebase repository located outside DBMS 570. Metadata 530 may contain version information specifying the minimum, maximum, or range of version numbers acceptable for implementing a missing dependency.

[0097] When dependency 541 depends on dependency 543, metadata 530 may contain nested data structures to indicate a dependency hierarchy. For example, metadata 530 may be encoded as hierarchical JSON or XML. For example, JSON dictionaries may be naturally nested, such as an inner dictionary within an outer dictionary, without needing to be flattened.

[0098] An outer dictionary can describe dependency 541, and an inner dictionary can describe dependency 543. The JSON dictionary used for top-level dependencies 541-542 can be elements of a JSON array. For example, metadata 530 can be encoded as this JSON array. An exemplary JSON encoding is presented here later. Therefore, metadata 530 can be a nested structure, and DBMS 570 can traverse this nested structure with or without recursion (such as recursive queries or recursive functions). As explained earlier here and illustrated later here, the flattened dependency hierarchy can be extracted without recursion. For example, the flattened dependency hierarchy can be nested as elements of a JSON array containing metadata for each dependency in dependencies 541-543.

[0099] 6.0 Exemplary Bundling Processing

[0100] Figure 6 This is a flowchart describing exemplary client processing for configuring a visitor module used for dependency discovery performed by a DBMS. (See also...) Figure 5 discuss Figure 6 .

[0101] Step 602 extracts, infers, or otherwise obtains dependency metadata from one or more source files of the visitor module. If the source files are project configuration files as discussed above, the dependency metadata is extracted more or less directly from the project configuration file.

[0102] If the source file is a logic script, it may require analysis of some or all statements (such as lines of text) within the script to detect dependencies. For example, import directives within the script can be analyzed to detect dependencies.

[0103] Steps 604 and 606 generate an introspection detection tool, which, according to an embodiment, may or may not depend on the content of dependency metadata. For example, the introspection detection tool used in steps 604 and 606 may be an exact copy that can be inserted into any visitor module. Step 604 generates an introspection function that returns dependency metadata. Step 606 generates a database call specification for invoking the introspection function from database statements (such as DML).

[0104] In embodiments not shown, the bundling step occurs between steps 604 and 606. For example, the client program may generate a bundle file directly or indirectly using a third-party tool, the bundle file containing some or all of the individual artifacts subsequently sent in step 606.

[0105] Step 606 automatically sends specific deliverables to the DBMS, such as at least one source file as part of a guest module, metadata specifying dependencies, introspection functions, and / or database call specifications for the introspection functions. For example, these deliverables may reside in a bundled file sent to the DBMS in step 606, such as before (i.e., pre-provided) defining a guest module within the DBMS using DDL, or when defining a guest module within the DBMS using DDL. In embodiments, the client program also includes a file uploader in addition to ODBC or other database drivers.

[0106] In an embodiment where files are pushed, the DBMS listens on an HTTP socket, and the file uploader sends a bundled file to the DBMS via that socket, such as through a public gateway interface (CGI). In an alternative embodiment where files are pulled, the file uploader listens on an HTTP socket, and the DBMS requests the socket to send a bundled file as identified by the URL, which the DBMS may have received from the client in a DDL command used to create a guest module.

[0107] 7.0 Exemplary Dependency Resolution Processing

[0108] The following is an exemplary embodiment based on Oracle DBMS and Oracle's Multilingual Engine (MLE). This embodiment uses technologies and components defined in the following context and further explained in related application 16 / 556,760, such as MLE, Truffle, Graal, Substrate, JIT, and Futamura projection. As used below, the MLE language is the guest language; the MLE module is the guest module; and the MLE function is the guest function.

[0109] MLE brings a multi-language framework to Oracle databases. The purpose of MLE is to enable developers to implement stored procedures or user-defined functions (UDFs) in languages ​​other than PL / SQL, Java, or C. MLE excels at executing dynamic languages ​​such as JavaScript, Ruby, Python, or R. However, MLE is not limited to dynamic languages ​​and can also run statically typed languages ​​such as Java.

[0110] The multi-language framework comprises several layers. The top layer is the implementation of the guest language. Each language implementation running on the MLE is based on Oracle Truffle, which is the first software implementation layer of the MLE. Truffle is a language implementation framework used to build a high-performance Abstract Syntax Tree (AST) interpreter that runs on a virtual machine (VM). Each node in the Truffle AST has an execution method in which it executes its child nodes and returns its own result. The main advantage of the Truffle AST interpreter is that it self-optimizes using dynamic profile information.

[0111] This profile is collected during the execution of the guest language program. Significant optimizations include type specification, rewriting indirect function calls, polymorphic inlining caching, branch elimination, and speculative function inlining. If these speculative assumptions prove false, the special-purpose tree can be reverted to a more general version that provides functionality for more general cases.

[0112] When the execution count of a Truffle node reaches a predefined threshold, Truffle triggers a partial evaluation by invoking Oracle Graal. Graal is the dynamic compiler that constitutes the second MLE layer. Graal is the Just-In-Time (JIT) compiler for MLE, performing partial evaluations of different parts of the AST. Specifically, the first Futamura Projection is applied here. The output of Graal is highly optimized machine code with optimization points removed.

[0113] These points are implemented as checkpoints, where deoptimization should be triggered if one or more speculative assumptions no longer hold. Deoptimization means that control is transferred from the compiled code back to the AST interpreter, where specialized nodes are then reverted to more general versions.

[0114] The third layer is the VM. MLE uses Substrate VM (SVM), which is an embeddable VM that provides services such as code caching or garbage collection.

[0115] An MLE language is any programming language supported by MLE. MLE is a Truffle language. The overall goal of MLE is to define the same concepts, requirements, features, and client interfaces for all MLE languages ​​in a unified way.

[0116] An MLE module is a unit of MLE language code deployed in an Oracle relational DBMS (RDBMS). Each MLE module is associated with a single MLE language, and its content and structure are dedicated to that MLE language.

[0117] Functions defined in an MLE module can be called from PL / SQL via the calling specification. MLE functions are functions exported by the deployed MLE module and can be called from PL / SQL as user-defined functions or as stored procedures via the PL / SQL calling specification.

[0118] Below is a DDL example for configuring the MLE language code to be executed according to the PL / SQL calling specification for MLE functions.

[0119] CREATE OR REPLACE FUNCTION

[0120] concat(str1 IN VARCHAR2,str2 IN VARCHAR2)AS MLE MODULE jsmodule

[0121] SIGNATURE'concat(str1 string,str2 string)';

[0122] Each MLE function declaration is based on an MLE module. For the functions above, the corresponding MLE module is created by the example DDL below.

[0123]

[0124] The above functions can be called as any of the following user-defined functions.

[0125] SELECT CONCAT('HELLO','World!')FROM DUAL

[0126] The programming language ecosystem is as follows. Modern programming languages ​​(such as JavaScript and Python) benefit from a rich and vast ecosystem of publicly available libraries and add-ons in the form of wrappers or native language modules. Logically, database users can deploy MLE modules containing such wrappers or modules, which have become available through wrapper managers (such as NPM or Pip). However, open-source wrappers or modules often undergo frequent version changes due to active development or security patches and updates.

[0127] The code deployment for privileged users is as follows. MLE provides a rich privilege model for creating MLE modules and invocation specifications:

[0128] ●CREATE MLE MODULE privilege: Users can deploy MLE modules in their own schemas.

[0129] ●CREATE ANY MLE MODULE privilege: A user can deploy an MLE module in another user's schema.

[0130] ●CREATE PROCEDURE privilege: Users can create MLE functions in their own schemas.

[0131] ●CREATE ANY PROCEDURE privilege: A user can create MLE functions in another user's schema.

[0132] The privileged model allows users granted the privileges to CREATE MLE MODULE or CREATE ANY MLE MODULE to deploy guest language code into Oracle RDBMS. This contrasts sharply with industry practice where only database administrators (DBAs) can deploy code. However, this presents new challenges: database administrators may have limited or no understanding of the deployed code. Therefore, as in this exemplary embodiment, a crucial requirement of the MLE architecture is the ability to introspect the encapsulations and modules included in the MLE module.

[0133] One of the responsibilities of a database administrator is the security and integrity of an RDBMS. One of the biggest security concerns regarding RDBMS security and integrity is unauthorized access to data. Because the Model Execution Module (MLE) is executed in the foreground process of an Oracle RDBMS, it can be used as a medium for exploiting data managed by the RDBMS. This is a significant concern because portions of the source code deployed as an MLE module may originate from public repositories that are more or less uncontrolled.

[0134] As discussed above, the MLE provides a rich privilege model that allows users who are not database administrators to deploy code, provided they have the necessary privileges. However, this technological advancement comes at a cost: a lack of transparency for database administrators regarding the encapsulation deployed by other users.

[0135] For the reasons mentioned above, module and encapsulation dependency introspection can be a significant architectural concern for MLE. This exemplary embodiment includes a solution: two directory views, which can be database views. The first directory view is MLE_MODULE_INTROSPECTION_VIEW, which lists the following attributes:

[0136] ●MLE Module Mode

[0137] ●MLE module name

[0138] ●Module / Package Name

[0139] ●Module / Package Version

[0140] ●Integrity information as a hash of the Secure Hash Algorithm (SHA)

[0141] ●Source URL

[0142] ●devDependency: A boolean value indicating whether this module / package is devDependency-sensitive.

[0143] MLE_MODULE_INTROSPECTION_VIEW lists all module / encapsulation dependencies of an MLE module, but provides no information about the hierarchy of module / encapsulation dependencies. For example, MLE module A includes NPM module B. Similarly, NPM module B requires NPM module C. Module A can be automatically augmented using the introspection detection tool that includes hierarchical dependency metadata. For example, the detection tool logic can be: automatically appended to a handwritten JavaScript script (not shown) that implements the original logic of module A, or executed as a separate script within the same guest language interpretation / execution context.

[0144]

[0145]

[0146]

[0147] From MLE_MODULE_INTROSPECTION_VIEW, it can be determined that MLE module A contains both NPM module B and NPM module C. Module B can be automatically augmented using the introspection detection tool that includes hierarchical dependency metadata. For example, the detection tool logic can be: automatically appended to a handwritten JavaScript script (not shown) that implements the original logic of module B, or executed as a separate script in the same guest language interpretation / execution. Execution is sticky in such a sense that global objects (such as variables, such as mlePackageIntrosptExptCnt) remain available to: other script statements that appear later in the same script and other scripts subsequently called for the same execution, having more or less the same effect as sequentially concatenating (i.e., appending) these multiple scripts into a single script. For example, the bundling and / or detection tool can more or less extensively depend on the concatenation of entire scripts and / or script statements (i.e., lines of text). Below is the dependency detection tool for JavaScript module B.

[0148]

[0149]

[0150] It may not be easy to infer the dependency of NPM module B on NPM module C from MLE_MODULE_INTROSPECTION_VIEW. This transitive dependency information can be obtained from a second directory view, MLE_MODULE_CONTENT_HIERARCHY_VIEW, which has the following properties:

[0151] ●MLE Module Mode

[0152] ●MLE module name

[0153] ●Module / Package Name

[0154] ●Module / Package Version

[0155] ● Module / package dependency: The modules / packages that this module / package depends on.

[0156] Information displayed in the catalog view can be used to inform decisions, such as whether deployed MLE modules should be updated and redeployed. For example, module / package bundle information can be cross-referenced using a list of available software patches or version upgrades.

[0157] The introspection information is generated as follows. MLE is provided with an auxiliary deployment tool. For JavaScript, this tool is called dbjs, and for Python, it is called dbpy. The deployment tool is responsible for:

[0158] ●Source code bundling

[0159] ● Deployment of MLE modules

[0160] ● The generation of calling specifications

[0161] Bundling infrastructure is used to generate introspection information when bundling guest code. For example, the JavaScript tool dbjs is based on Webpack. Specifically, different plugins are provided that integrate with the Webpack infrastructure. Another plugin is needed to generate introspection information. However, bundling information can also be generated from specific project configuration files, which different package managers use to download and serve various open-source packages, modules, or libraries. The underlying file used for NPM is, for example, called package.json or package-lock.json. Apache's other resource negotiator (Yarn) uses a file named yarn.lock. In the case of Pip, it is called pipfile.

[0162] The introspection information is embedded and exported in the MLE module as follows. The introspection information is exported as a nested data type, such as JSON or XML. This exemplary embodiment uses JSON.

[0163] The two examples below show how to embed introspection information in an MLE module. Here, it is shown for two MLE modules. For most MLE languages, it is best to do so by implementing a function that returns a nested data type to export the JSON value.

[0164] Across all MLE modules and MLE languages, the same name should be used for exported functions. In the following examples, dependency metadata embedding is facilitated by a function called `mlePackageIntrosptExptFunc`. As shown in the figure, both visitor modules A and B (the source code is shown later below) export the same function. In both examples, the encapsulation information is stored in the field `mlePackageIntrosptExptCnt`.

[0165] The auxiliary deployment tool can be configured to include not only the source code in the MLE module, but also to create a calling specification for the exported function `mlePackageIntrosptExptFunc`. Specifically, an additional scalar function called `MLEPACKAGEINTROSPTEXPTFUNC` is embedded in the PL / SQL wrapper definition of all exported calling specifications of the deployed MLE module. The code excerpt below is the PL / SQL wrapper definition for module A.

[0166] CREATE PACKAGE MODULE_A_PACKAGE AS ...

[0168] FUNCTIONMlePackageIntrosptExptFunc

[0169] RETURN VARCHAR2

[0170] AS MLE MODULE MODULE_A

[0171] SIGNATURE'mlePackageIntrosptExptFunc()' ...

[0173] END MODULE_A_PACKAGE;

[0174] The directory view is defined as follows. To display introspection information in a directory view format, a scalar function should be used, which takes the schema and name of the MLE module as arguments. Using this information, the scalar function calls the predefined PL / SQL wrapper (shown above) of the MLE function MlePackageIntrosptExptFunc to export the introspection information in JSON format. The scalar function MlePackageIntrosptExptFuncInvoc is called, for example, using the following logic.

[0175] CREATE OR REPLACE FUNCTION

[0176] MLEPACKAGEINTROSPTEXPTFUNCINVOC

[0177] (schema VARCHAR,name VARCHAR)RETURN VARCHAR2

[0178] AS

[0179] cmd VARCHAR(256); result VARCHAR(4000);

[0180] BEGIN

[0181] cmd:='SELECT'

[0182] ||Ltrim(Rtrim(schema))

[0183] ||'.'

[0184] ||Ltrim(Rtrim(name))

[0185] ||'.MLEPACKAGEINTROSPTEXPTFUNC()from dual';

[0186] EXECUTE IMMEDIATE cmd INTO result;

[0187] RETURN result;

[0188] END;

[0189] The `MLE_MODULE_INTROSPECTION_VIEW` has a view definition with the following PL / SQL code. This view utilizes a public table expression represented by the `js` (WITH clause). Within the `js`, for each deployed MLE module, `MlePackageIntrosptExptFuncInvoc` is called. The following code calls `JSON_TABLE`, as discussed earlier here.

[0190] The details of the SQL / JSON path expression syntax for JSON_TABLE will be presented later here in the section “SQL / JSON Path Expression Syntax for JSON_TABLE”. Note that: absolute path expressions begin with a dollar sign ($); relative path expressions begin with an at sign (@); and [*] selects all elements of the array. Below is the definition of MLE_MODULE_INTROSPECTION_VIEW.

[0191]

[0192]

[0193] Collect a list of deployed MLE modules from all objects in the directory view. The result in the js file is a list of the following items:

[0194] ● Deployment mode of MLE module (owner),

[0195] ● The name of the MLE module (mle_module_name), and

[0196] ● Introspection information (info) in JSON format.

[0197] The FROM clause reveals extensive use of the JSON_TABLE query extension for SQL. The deployed module name is obtained by reading the name attribute of the JSON via the top-level COLUMNS clause. Since the different dependencies of the guest modules are arrays of JSON objects of the global variable mlePackageIntrosptExptCnt as shown earlier, the NESTED PATH feature is used.

[0198] Figure 7 The results of a direct selection query of the MLE_MODULE_INTROSPECTION_VIEW are displayed for the exemplary deployment of module A and module B. The MLE_MODULE_INTROSPECTION_VIEW lists all bundled modules and encapsulations involved in the creation of the MLE module. However, for the module / encapsulation dependency hierarchy, a second view needs to be queried, which is defined by the following logic: MLE_MODULE_CONTENT_HIERARCHY_VIEW.

[0199]

[0200]

[0201] The view definition above is very similar to MLE_MODULE_INTROSPECTION_VIEW, but has an import exception. For MLE_MODULE_CONTENT_HIERARCHY_VIEW, the second-level NESTED PATH expression normalizes the content of nested dependency JSON ARRAYs. Figure 8 The results of a direct selection query for MLE_MODULE_CONTENT_HIERARCHY_VIEW are displayed for an exemplary deployment of Module A and Module B.

[0202] 8.0 SQL / JSON path expression syntax for JSON_TABLE

[0203] The syntax for SQL / JSON path expressions, such as those used with JSON_TABLE, is as follows. SQL / JSON path expressions are used by SQL / JSON functions and conditions to match JSON data to select a portion of it. Path expressions can use wildcards and array ranges. Matching is case-sensitive. To use them, you need to pass the SQL / JSON path expression and some JSON data to an SQL / JSON function (such as JSON_TABLE) or an SQL / JSON condition. The path expression is matched against the data, and the matched data is processed by a specific SQL / JSON function or condition. The matching processing operation causes the path expression to return the matched data to the function or condition.

[0204] The basic SQL / JSON path expression syntax is as follows. It provides the basic syntax for SQL / JSON path expressions. It includes a context bullet point ($), followed by zero or more objects, arrays, and descendant steps. Each descendant step can be followed by a filter expression, which can optionally be followed by a function step. Examples are provided here.

[0205] The SQL / JSON path expression syntax has been relaxed as follows. The basic SQL / JSON path expression syntax has been relaxed to allow implicit array wrapping and expansion. This means that if the data evolves to replace JSON values ​​with arrays utilizing such values, there is no need to change the path expressions in the original visitor module code, and vice versa. An example is provided here later.

[0206] The basic syntax of SQL / JSON path expressions is as follows. It includes a context bullet point ($), followed by zero or more objects, arrays, and descendant steps. Each descendant step can be followed by a filter expression, which can optionally be followed by a function step. An example is provided.

[0207] However, this basic syntax is extended by relaxing the matching of arrays and non-arrays with non-array and array patterns, respectively. Matching data with SQL / JSON path expressions is case-sensitive. Basic SQL / JSON path expressions (here simply referred to as path expressions) are either absolute or relative path expressions.

[0208] An absolute path expression begins with a dollar sign ($), which represents the path expression context item, that is, the JSON data to be matched. This data is the result of evaluating an SQL expression passed as an argument to an SQL / JSON function. The dollar sign is followed by zero or more non-function steps, followed by optional function steps.

[0209] A relative path expression is represented by the at symbol (@), followed by zero or more non-functional steps, and optionally functional steps. It has the same syntax as an absolute path expression, except that it uses the at symbol instead of the dollar sign ($).

[0210] Relative path expressions are used inside filter expressions (or simply filters). The `at` symbol represents the current filter item of the path expression, that is, the JSON data that matches the portion of the (surrounding) path expression preceding the filter containing the relative path expression. Relative path expressions match the current filter item in the same way that absolute path expressions match context items.

[0211] Non-function steps are object steps, array steps, or descendant steps, followed by an optional filter expression. A single function step is optional in the basic path expression (absolute or relative). If present, it is the last step in the path expression. It is a period (.), sometimes read as "dot," followed by an SQL / JSON item method, then a left parenthesis ((), followed by a right parenthesis (). The parentheses can have spaces between them (this space is irrelevant).

[0212] The item method is applied to data targeted by the remainder of the same path expression preceding the function step. The item method is used to transform that data. SQL functions or conditions that pass the path expression as an argument use the transformed data, not the target data.

[0213] The object step is a period (.) followed by the object field name or an asterisk (*) wildcard, representing the values ​​of all fields. Field names can be empty; in this case, they must be written as "" (without spaces). Non-empty field names must begin with an uppercase or lowercase letter A through Z and contain only such letters or decimal digits (0-9); otherwise, they must be enclosed in double quotes ("). The object step returns the value of the specified field. If a wildcard is used for a field, the step returns the values ​​of all fields without any special order.

[0214] An array step is a left square bracket ([), followed by an asterisk (*) wildcard representing all array elements or one or more specific array indices or range specifications separated by commas (), followed by a right square bracket (]). Using both an asterisk and an array index or range specification will result in an error.

[0215] In path expressions, array indices are zero-based (0, 1, 2, ...), similar to the JavaScript conventions for arrays. The range specification has indices from N to M, where N and M are array indices and N is strictly less than M.Foot 1. If N is not less than M, an error occurs during query compilation.

[0216] When using index or range specifications, the array elements they jointly specify must be specified in ascending order without repetition; otherwise, a compile-time error will occur. For example, errors will occur for each of [3,1 to 4], [4,2], [2,3 to 3], and [2,3,3]. The first two will produce errors because the order is not ascending, and the last two will produce errors because of the duplicate array index 3 (which indexes the fourth array element based on zero-based indexing).

[0217] Similarly, the elements in the array value obtained by matching are in ascending order, with no duplicates. If an asterisk is used in the path expression, all array elements are returned in array order.

[0218] Descendant steps are two consecutive periods (..), sometimes read as "dots," followed by field names (which have the same syntax as object steps). They recursively descend to the object or array that matches their predecessor (or, if no predecessor exists, to the context item).

[0219] At each descendant level, for each object and for each array element that is an object, it collects the values ​​of all fields with the specified names. It returns all collected field values. For example, consider this query and data:

[0220]

[0221] The query returns an array, such as [1,2,3], whose elements are 1, 2, and 3. It collects the value of each field z within the preceding step as a dot (..) of field a. The topmost field z with the value 4 does not match because it is not within the values ​​of field a.

[0222] The value of field a is an object that descends. It has a field z, the value of which (3) is collected. It also has a field b, the value of which is an object that descends to collect the value of its field z, which is 1. It also has a field c, the value of which is an array that has elements that are objects with field z, the value of which (2) is collected. The collected JSON values ​​are therefore 3, 1, and 2. They are wrapped in an array in an undefined order. One of the possible return values ​​is [1, 2, 3].

[0223] A filter expression (or simply filter) is a question mark (?) followed by a filter condition enclosed in parentheses (()). The filter is satisfied if the filter condition is met, that is, if it returns true. The filter condition applies a predicate (a Boolean function) to its argument and is one of the following, where each of cond, cond1, and cond2 represents a filter condition.

[0224] ●(cond): Parentheses are used for grouping, separating the filter condition cond as a unit from other filter conditions that may precede or follow it.

[0225] ●cond1&&cond2: The conjunction (and) of cond1 and cond2 requires both to satisfy the condition.

[0226] ●cond1||cond2: The inclusion disjunction (or) of cond1 and cond2, which requires cond1, cond2 or both to satisfy the condition.

[0227] ●! (cond): The negation of cond means that cond can never be satisfied.

[0228] ●exists(, followed by a relative path expression, followed by ): The condition that the target data exists (remains).

[0229] ●Comparison: It is one of the following:

[0230] ○ Relative path expression, followed by a comparison predicate, followed by a JSON scalar value or SQL / JSON variable.

[0231] ○ A JSON scalar value or an SQL / JSON variable, followed by a comparison predicate, and then a relative path expression.

[0232] ○ A JSON scalar value, followed by a comparison predicate, followed by another JSON scalar value.

[0233] ○ A relative path expression, followed by has substring, starts with, like, like_regex or eq_regex, followed by a JSON string or an SQL / JSON variable bound to an SQL string (which is automatically converted from the database character set to UTF8).

[0234] ■has substring means: the matched data value has the specified string as a substring.

[0235] ■starts with means: the matched data values ​​have the specified string as a prefix.

[0236] ■LIKE means: The JSON string data value matches the specified string, which is interpreted as a SQL LIKE pattern using the SQLLIKE4 character set semantics. The percent sign (%) in this pattern matches zero or more characters. The underscore (_) matches a single character.

[0237] ■ Note that unlike SQL LIKE, there are no escape characters for the path expression predicate LIKE. It is recommended to avoid using the backtick character (`) in LIKE patterns. GRAVE ACCENT (U+0060) — this character (sometimes called a backtick or reverse checkmark) is reserved for future use.

[0238] ■like_regex means: JSON string data value matches the specified string, which is interpreted as the SQL REGEXP LIKE regular expression pattern using SQL LIKE4 character set semantics.

[0239] ■like_regex is an exception in pattern matching comparisons because its pattern matches an empty JSON string ("").

[0240] ■eq_regex is similar to like_regex, except for these two differences:

[0241] ● `eq_regex` matches its regular expression pattern against the entire JSON string data value—the complete string must match the pattern to satisfy the comparison. If any part of the JSON string matches the pattern, then `like_regex` is satisfied.

[0242] ●The eq_regex pattern does not match an empty JSON string ("").

[0243] For all these predicates, patterns that are empty strings ("") match data that are empty strings. And for all patterns except like_regex, patterns that are not empty strings do not match data that are empty strings. For like_regex, non-empty patterns match empty string data.

[0244] ○ A relative path expression, followed by "in", followed by a list of values, means that the value is one of those values ​​in the list.

[0245] The comparison predicates are ==, <>, ! = Foot 2, <, <=, >= or >, which respectively represent equal to, not equal to, less than, less than or equal to, greater than or equal to, and greater than.

[0246] SQL / JSON variables are dollar signs ($) followed by the name of the SQL identifier bound in the PASSING clause of json_exists.

[0247] The list of values ​​is (, followed by a list of one or more scalar values ​​and SQL / JSON variables separated by commas (,), followed by ).

[0248] The predicates that can be used in filter conditions are therefore &&, ||, !, exists, ==, <>, ! =, <, <=, >=, >, and in.

[0249] As an example, if both of the following criteria are met, then the filter condition (a||b)&&(!(c)||d<42) is satisfied:

[0250] ● At least one of the filter conditions a and b must satisfy: (a||b).

[0251] ● Filter condition c is not met, or the quantity d is less than or equal to 42, or both are true: (!(c)||d<42).

[0252] Comparison predicates: ! takes precedence over &&, and && takes precedence over ||. Parentheses can always be used to control grouping.

[0253] Without parentheses for grouping, the previous example would be a||b&&! (c)||d<42, which is satisfied if at least one of the following criteria is met:

[0254] ●Condition b && ! (c) are satisfied, which means that each of conditions b and ! (c) is satisfied (which in turn means that condition c is not satisfied).

[0255] ●Condition a is satisfied.

[0256] ●The condition d<42 is satisfied.

[0257] At least one side of the comparison must not be an SQL / JSON variable. The default type for comparison is defined at compile time based on the type of the non-variable side. This default can be overridden using type-specified item methods. For comparison, the type of the matching data is automatically converted to fit the specified type (either by default or specified by the item method). For example, `$.a>5` forces a numeric comparison because 5 is a number, and `$.a>"5"` forces a string comparison because "5" is a string.

[0258] It's important to note that for robust full-text search, using the Oracle SQL function `json_textcontains` may require creating a JSON search index. As a less robust alternative, if you don't want to create a JSON search index and prefer simple string pattern matching in your filter conditions, you can use any pattern matching comparison: `hassubstring`, `starts with`, `like`, `like_regex`, or `eq_regex`.

[0259] Here are some examples of path expressions, with their meanings explained in detail.

[0260] ●$–Context Items

[0261] ● $.friends – The value of the friends field in the context item object. The dot (.) immediately following the dollar sign ($) indicates that the context item is a JSON object.

[0262] ●$.friends[0] – An object containing the first element of an array of values ​​for the field friends, which is the context item object. The square brackets indicate that the values ​​for the field friends are an array.

[0263] ● $.friends[0].name – The value of the field name of the first element of the array of values ​​for the friends field of the context item object. The second dot (.) indicates that the first element of the friends array is the object (with the name field).

[0264] ● $.friends[*].name – The value of the field name for each object in the array of values ​​for the friends field of the context item object.

[0265] ● $.*[*].name – The field name value of each object in the array of fields of the context item object.

[0266] ● $.friends[3,8 to 10,12] – The fourth, ninth through eleventh, and thirteenth elements of the array friends (fields of the context item object). The elements must be specified in ascending order, and they are returned in that order: fourth, ninth, tenth, eleventh, thirteenth.

[0267] ●$.friends[3].cars – The value of the cars field of the object that is the fourth element of the array friends. The dot (.) indicates that the fourth element is an object (with the cars field).

[0268] ●$.friends[3].* – Values ​​of all fields of the object that is the fourth element of the array friends.

[0269] ●$.friends[3].cars[0].year – The value of the field 'cars' of the object that is the fourth element of the array friends, and the value of the field 'year' of the object that is the first element of the array friends.

[0270] ●$.friends[3].cars[0]? (@.year>2016) – The first object of the array `cars` (the field of the object that is the fourth element of the array `friends`), provided that the value of its field `year` is a number greater than 2016, or can be converted to a number greater than 2016. Year values ​​such as "2017" are converted to the number 2017, which satisfies the test. Year values ​​such as "recent" fail the test – do not match.

[0271] ●$.friends[3].cars[0]? (@.year.number()>2016) – Same as the previous expression. The item method number() only allows numbers or string values ​​that can be converted to numbers, and this behavior is already provided by the number comparison predicate >.

[0272] ●$.friends[3].cars[0]? (@.year.numberOnly()>2016) – Same as the previous expression, but the year value is only a number. The item method numberOnly() excludes cars whose year value is a string number (such as "2017").

[0273] ●$.friends[3]? (@.addresses.city=="San Francisco") – An object that is the fourth element of the array friends, provided that it has an addresses field whose value is an object with a city field whose value is the string "San Francisco".

[0274] ●$.friends[*].addresses? (@city starts with "San").zip – a zip code for all addresses in friends, where the city name of the address starts with "San". (In this case, the filter is not the last path step.)

[0275] ●$..zip – All values ​​for the zip field anywhere at any level.

[0276] ●$.friends[3]? (@.addresses.city=="San Francisco"&&@.addresses.state=="Nevada") – The object that is the fourth element of the array friends, provided that there is a match for an address with the city "San Francisco" and a match for an address with the state "Nevada".

[0277] ● Note that filter conditions in a conjunction do not necessarily apply to the same object – the filter tests the existence of objects with the city of San Francisco and the state of Nevada. It does not test the existence of objects that have both the city of San Francisco and the state of Nevada. See Using filters with JSON_EXISTS.

[0278] ●$.friends[3].addresses? (@.city=="San Francisco"&&@.state=="Nevada") – The object that is the fourth element of the array friends, provided that the object matches the city "San Francisco" and the state "Nevada".

[0279] Unlike the previous example, in this case, the filter conditions in the conjunction of the fields city and state are applied to the same addresses object. The filter is applied to a given addresses object outside of it.

[0280] 9.0 Database Overview

[0281] Embodiments of the present invention are used in the context of a database management system (DBMS). Therefore, a description of an exemplary DBMS is provided.

[0282] Typically, a server (such as a database server) is a combination of integrated software components and the allocation of computing resources (such as memory, nodes, and processes on those nodes for executing the integrated software components), where the combination of software and computing resources is dedicated to providing a specific type of functionality on behalf of clients. A database server controls and facilitates access to a specific database and handles client requests to access that database.

[0283] Users interact with the DBMS database server by submitting commands to the database server, instructing the database server to perform operations on the data stored in the database. A user can be one or more applications running on the client computer interacting with the database server. Multiple users can also be collectively referred to as users here.

[0284] A database consists of data and a database dictionary, which is stored on a persistent storage facility (such as a set of hard drives). A database is defined by its own separate database dictionary. The database dictionary includes metadata that defines the database objects contained within the database. In fact, the database dictionary defines most of the database. Database objects include tables, table columns, and tablespaces. A tablespace is a set of one or more files used to store data for various types of database objects (such as tables). If the data of a database object is stored in a tablespace, the database dictionary maps the database object to one or more tablespaces that hold the data for the database object.

[0285] The database dictionary is referenced by the DBMS to determine how to execute database commands submitted to the DBMS. Database commands can access database objects defined by the dictionary.

[0286] Database commands can take the form of database statements. For a database server to process database statements, those statements must conform to a database language supported by the database server. A non-limiting example of a database language supported by many database servers is SQL, including proprietary forms of SQL supported by database servers such as Oracle (e.g., Oracle Database 11g). SQL Data Definition Language (“DDL”) instructions are issued to the database server to create or configure database objects, such as tables, views, or complex types. Data Manipulation Language (“DML”) instructions are issued to the DBMS to manage data stored within database structures. For example, SELECT, INSERT, UPDATE, and DELETE are common examples of DML instructions found in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in object-relational databases.

[0287] A multi-node database management system comprises interconnected nodes that share access to the same database. Typically, these nodes are interconnected via a network and share access to shared storage devices to varying degrees, such as shared access to a set of disk drives and the blocks of data stored on them. Nodes in a multi-node database system can take the form of a group of computers (such as workstations and / or personal computers) interconnected via a network. Alternatively, the nodes can be nodes in a grid, which comprises nodes in the form of server blades interconnected with other server blades on a rack.

[0288] In a multi-node database system, each node hosts a database server. A server (such as a database server) is a combination of integrated software components and computing resources (such as memory, nodes, and processes on the nodes for executing the integrated software components on the processor), a combination of software and computing resources dedicated to performing a specific function on behalf of one or more clients.

[0289] Resources from multiple nodes in a multi-node database system can be allocated to run software for a specific database server. Each combination of software and allocation of resources from the nodes constitutes a server, referred to herein as a "server instance" or "instance". A database server may include multiple database instances, some or all of which may run on separate computers (including separate server blades).

[0290] 9.1 Query Processing

[0291] A query is an expression, command, or set of commands that, when executed, causes a server to perform one or more operations on a dataset. A query may specify one or more source data objects, such as one or more tables, one or more columns, one or more views, or one or more snapshots, from which one or more result sets will be determined. For example, the source data objects may appear in the FROM clause of a Structured Query Language (“SQL”) query. SQL is a well-known exemplary language for querying database objects. As used herein, the term “query” is used to refer to any form representing a query, including queries having the form of database statements and any data structure used for inner query representation. The term “table” refers to any source object referenced or defined by a query and representing a set of rows, such as a database table, view, or inline query block, such as an inline view or subquery.

[0292] Queries can perform operations on data from the source data objects row by row as the source data objects are loaded, or on all source data objects after the source data objects have been loaded. The result sets produced by some operations can be used for one or more other operations, and in this way, the result sets can be filtered or narrowed based on some criteria, and / or combined or combined with one or more other result sets and / or one or more other source data objects.

[0293] A subquery is a part or component of a query that is distinct from the other parts or components of the query and can be evaluated separately (i.e., as a separate query) from the other parts or components of the query. The other parts or components of the query may form an outer query, which may or may not include other subqueries. When evaluating the results for the outer query, subqueries nested within the outer query may be evaluated individually once or multiple times.

[0294] Typically, a query parser receives a query statement and generates an internal query representation of that statement. This internal query representation is usually a set of interconnected data structures that represent the various components and structure of the query statement.

[0295] Internal query representations can take the form of a graph of nodes, where each interconnected data structure corresponds to a node and a component of the query statement it represents. Internal representations are typically generated in memory for evaluation, manipulation, and transformation.

[0296] Hardware Overview

[0297] According to one embodiment, the technology described herein is implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to execute the technology, or may include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) permanently programmed to execute the technology, or may include one or more general-purpose hardware processors programmed to execute the technology according to program instructions in firmware, memory, other storage devices, or a combination thereof. Such a dedicated computing device may also combine custom hardwired logic, ASICs, or FPGAs with custom programming to implement the technology. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device including hardwired and / or program logic for implementing the technology.

[0298] For example, Figure 9 This is a block diagram illustrating a computer system 900 that can implement embodiments of the present invention. The computer system 900 includes a bus 902 or other communication mechanism for transmitting information and a hardware processor 904 coupled to the bus 902 for processing information. The hardware processor 904 may be, for example, a general-purpose microprocessor.

[0299] Computer system 900 also includes main memory 906 (such as random access memory (RAM) or other dynamic storage devices), which is coupled to bus 902 to store information and instructions executed by processor 904. Main memory 906 can also be used to store temporary variables or other intermediate information during the execution of instructions executed by processor 904. When such instructions are stored in non-transitory storage media accessible to processor 904, these instructions turn computer system 900 into a dedicated machine customized to perform the operations specified in those instructions.

[0300] The computer system 900 also includes a read-only memory (ROM) 908 or other static storage device coupled to a bus 902 to store static information and instructions for the processor 904. A storage device 910 (such as a disk, optical disk, or solid-state drive) is provided and coupled to the bus 902 to store information and instructions.

[0301] Computer system 900 may be coupled to display 912 (such as a cathode ray tube (CRT)) via bus 902 to display information to the computer user. Input device 914 (including alphanumeric and other keys) is coupled to bus 902 to transmit information and command selections to processor 904. Another type of user input device is a cursor controller 916 (such as a mouse, trackball, or cursor arrow keys) for transmitting directional information and command selections to processor 904 and for controlling cursor movement on display 912. This input device typically has two degrees of freedom along two axes (a first axis (e.g., x) and a second axis (e.g., y)), which allows the device to specify a position in a plane.

[0302] Computer system 900 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in conjunction with the computer system, turn computer system 900 into a special-purpose machine or program the computer system 900 to become a special-purpose machine. According to one embodiment, the techniques are executed herein by computer system 900 in response to processor 904 executing one or more sequences of one or more instructions contained in main memory 906. Such instructions may be read into main memory 906 from another storage medium (such as storage device 910). Execution of the sequence of instructions contained in main memory 906 causes processor 904 to perform the processing steps described herein. In alternative embodiments, hardwired circuitry may be used instead of software instructions or in combination with software instructions.

[0303] As used herein, the term "storage medium" means any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs, magnetic disks, or solid-state drives, such as storage device 910. Volatile media include dynamic memory, such as main memory 906. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cartridges.

[0304] Storage media differ from transmission media, but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, which include conductors comprising bus 902. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0305] Various forms of media can be used to transmit one or more sequences of one or more instructions to processor 904 for execution. For example, instructions may initially be transmitted on a disk or solid-state drive of a remote computer. The remote computer is able to load the instructions into its dynamic memory and transmit the instructions over a telephone line using a modem. The local modem of computer system 900 is able to receive data over the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector is able to receive the data transmitted in the infrared signal, and appropriate circuitry is able to place the data on bus 902. Bus 902 transmits the data to main memory 906, from which processor 904 fetches and executes instructions. Instructions received by main memory 906 may optionally be stored on storage device 910 before or after execution by processor 904.

[0306] Computer system 900 also includes a communication interface 918 coupled to bus 902. Communication interface 918 provides bidirectional data communication coupling with network link 920 connected to local network 922. For example, communication interface 918 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem for providing data communication connectivity with a corresponding type of telephone line. As another example, communication interface 918 may be a local area network (LAN) card for providing data communication connectivity with a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 918 transmits and receives electrical, electromagnetic, or optical signals that carry streams of digital data representing various types of information.

[0307] Network link 920 typically provides data communication with other data devices via one or more networks. For example, network link 920 may provide connection to host computer 924 or to data equipment operated by Internet Service Provider (ISP) 926 via local network 922. ISP 926, in turn, provides data communication services via the Global Packet Data Network (now commonly referred to as "the Internet" 928). Both local network 922 and Internet 928 use electrical, electromagnetic, or optical signals to transmit digital data streams. Signals through various networks, as well as signals on network link 920 and through communication interface 918 (which transmits digital data to and from computer system 900), are exemplary forms of transmission media.

[0308] Computer system 900 can send messages and receive data (including program code) through a network, network link 920, and communication interface 918. In the Internet example, server 930 can send application code for requests through Internet 928, ISP 926, local network 922, and communication interface 918.

[0309] When a code is received, the received code may be executed by processor 904, and / or the received code may be stored in storage device 910 or other non-volatile media for later execution.

[0310] Software Overview

[0311] Figure 10 This is a block diagram of a basic software system 1000 that can be used to control the operation of a computing system 900. The software system 1000 and its components (including their connections, relationships, and functions) should be considered exemplary only and are not intended to limit the implementation of the exemplary embodiments. Other software systems suitable for implementing the exemplary embodiments may have different components, including components with different connections, relationships, and functions.

[0312] Software system 1000 is provided to guide the operation of computing system 900. Software system 1000 (which may be stored in system memory (RAM) 906 and on a fixed storage device (e.g., hard disk or flash memory) 910) includes a kernel or operating system (OS) 1010.

[0313] OS 1010 manages the low-level aspects of computer operations, including managing process execution, memory allocation, file input and output (I / O), and device I / O. One or more applications, denoted as 1002A, 1002B, 1002C…1002N, can be “loaded” (e.g., transferred from fixed storage device 910 to memory 906) for execution by system 1000. Applications or other software intended for use on computer system 900 can also be stored, for example, as a set of downloadable computer-executable instructions for download and installation from an Internet location (e.g., a web server, app store, or other online service).

[0314] Software system 1000 includes a graphical user interface (GUI) 1015 for receiving user commands and data graphically (e.g., "click" or "touch gesture"). This input can then be manipulated by system 1000 according to instructions from operating system 1010 and / or (one or more) applications 1002. GUI 1015 also displays the results of the actions from OS 1010 and (one or more) applications 1002, allowing the user to provide additional input or terminate the session (e.g., log off).

[0315] OS 1010 can execute directly on the bare hardware 1020 of computer system 900 (e.g., one or more processors 904). Alternatively, a hypervisor or virtual machine monitor (VMM) 1030 can be inserted between the bare hardware 1020 and OS 1010. In this configuration, VMM 1030 acts as a software “buffer” or virtualization layer between OS 1010 and bare hardware 1020 of computer system 900.

[0316] VMM 1030 instantiates and runs one or more virtual machine instances (“guest machines”). Each guest machine includes a “guest” operating system (such as OS 1010) and one or more applications (such as (one or more) applications 1002) designed to run on the guest operating system. VMM 1030 provides a virtual operating platform for the guest operating system and manages the execution of the guest operating system.

[0317] In some instances, VMM 1030 allows a guest operating system to run as if it were running directly on the bare hardware 1020 of computer system 1000. In these instances, the same version of the guest operating system configured to run directly on the bare hardware 1020 can also run on VMM 1030 without modification or reconfiguration. In other words, in some instances, VMM 1030 provides full hardware and CPU virtualization to the guest operating system.

[0318] In other instances, for efficiency, the guest operating system may be specifically designed or configured to run on the VMM 1030. In these instances, the guest operating system "knows" that it is running on the virtual machine monitor. In other words, in some instances, the VMM 1030 can provide paravirtualization for the guest operating system.

[0319] A computer system process includes the allocation of hardware processor time and memory (physical and / or virtual) for storing instructions executed by the hardware processor, data generated by the hardware processor executing the instructions, and / or the hardware processor state (e.g., register contents) between the allocations of hardware processor time when the computer system process is not running. The computer system process runs under the control of the operating system and can also run under the control of other programs executing on the computer system.

[0320] cloud computing

[0321] The term "cloud computing" is often used here to describe a computing model that enables on-demand access to a shared pool of computing resources, such as computer networks, servers, software applications, and services, and allows for the rapid provisioning and release of resources with minimal management effort or service provider interaction.

[0322] Cloud computing environments (sometimes referred to as cloud environments or the cloud itself) can be implemented in various ways to best suit different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the general public. In contrast, private cloud environments are typically intended for use by or within a single organization. Community clouds are designed to be shared by several organizations within a community; while hybrid clouds include two or more types of clouds (e.g., private, community, or public) bound together by data and application portability.

[0323] Typically, cloud computing models enable some of the responsibilities that might have previously been provided by an organization's own IT departments to be delivered as service layers within the cloud environment for use by consumers (within or outside the organization, depending on the public / private nature of the cloud). Depending on the specific implementation, the precise definition of the components or features provided by each cloud service layer or within each cloud service layer can vary, but common examples include: Software as a Service (SaaS), where consumers use software applications running on cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications; Platform as a Service (PaaS), where consumers can use software programming languages ​​and development tools supported by the PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., all aspects below the runtime execution environment); and Infrastructure as a Service (IaaS), where consumers can deploy and run arbitrary software applications and / or provision processing, storage, networking, and other basic computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., all aspects below the operating system layer). Database as a Service (DBaaS) is a service where consumers use database servers or database management systems that run on cloud infrastructure, while the DBaaS provider manages or controls the underlying cloud infrastructure and applications.

[0324] For the purpose of representing the basic underlying computer components that can be used to implement the one or more exemplary embodiments, the aforementioned basic computer hardware and software and cloud computing environment are provided. However, the one or more exemplary embodiments are not necessarily limited to any particular computing environment or computing device configuration. Instead, the one or more exemplary embodiments can be implemented in any type of system architecture or processing environment, and those skilled in the art will understand, in light of this disclosure, that any type of system architecture or processing environment is capable of supporting the features and functions of the one or more exemplary embodiments provided herein.

[0325] In the foregoing description, embodiments of the invention have been described with reference to many specific details that may vary depending on the implementation. Therefore, the description and drawings are to be viewed in an illustrative rather than restrictive sense. The only specific indicator of the scope of the invention, and what the applicant intends to be the scope of the invention, is the wording and equivalents of the set of claims published from this application in the specific form of such claims, including any subsequent corrections.

Claims

1. A method for a database management system (DBMS), comprising: In each of one or more visitor modules defined in one or more visitor programming languages ​​implemented in a DBMS, logic is invoked to obtain metadata describing multiple dependencies that the visitor module depends on, wherein the metadata is JSON-encoded and includes nested data structures, wherein obtaining the metadata describing the multiple dependencies includes: invoking a table function that transforms and aggregates JSON data from separate documents into tabular data, wherein the table function is defined in a database dictionary; Generate a report on dependencies based on metadata describing the various dependencies; The dependency-based report identifies a subset of the various dependencies that a particular visitor module in one or more visitor modules depends on.

2. The method of claim 1, wherein for each of the plurality of dependencies, the reporting of the dependency includes at least one of the following: The timestamp when the implementation of this dependency was included in the DBMS, and / or Indicates whether the dependency is only used for development tags.

3. The method of claim 2, wherein the dependency is used only for developing tools that include the dependency for testing or for development purposes.

4. The method of claim 1, wherein the report generating the dependency or the subset of the multiple dependencies on which the specific visitor module depends includes: Use a database view based on metadata describing the various dependencies.

5. The method of claim 1, wherein at least one of the following: The method further includes generating a database call specification for each of the one or more visitor modules, and / or The acquisition of metadata describing the various dependencies includes: Invoke the database invocation specification for each of the one or more visitor modules.

6. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the execution of the steps of the method as described in any one of claims 1-5.

Images