Database environment for guest languages

Abstract

This document is about the technology of extending a software system to embed a new guest programming language (GPL) that interoperates in a transparent, modular, and configurable manner. In an embodiment, a computer inserts the implementation of the GPL into the deployment of the system. Commands register the GPL, define subroutines for the GPL, generate a guest virtual environment, and add dependencies to the bindings of guest modules. In an embodiment, the native programming language calls the guest programming language to enable importing intra-language or inter-language dependencies. Embodiments define guest objects implemented in a first GPL and accessed from a second GPL. In an embodiment, dependencies are retrieved from a virtual file system having several alternative implementation mechanisms, including: an archive file or a physical file system, and a column of a memory buffer or a database table.

Description

Technical Field

[0001] The present invention relates to multi - language programming of software systems such as database management systems (DBMS). It is a technique for extending software systems to embed new guest programming languages that interoperate in a transparent, modular, and configurable manner. Background Art

[0002] Modern programming languages such as JavaScript and Python benefit from an ecosystem of rich and large publicly available libraries and add - ons. However, database systems rarely or do not support multiple programming languages at all. For example, for JavaScript and Python, package management and package import have inconsistent methods that may be difficult or impossible to reconcile.

[0003] In the JavaScript ecosystem, the use of code - library bundling tools is common. Those tools resolve the package dependencies imposed by require statements by inlining the source code of the dependencies. The result of those bundling techniques is a single source file containing all the necessary source logic. For other language ecosystems, those bundling tools are not available.

[0004] Package management often relies on version control. Package managers such as NPM or Pip are able to handle package versions. NPM handles version control by organizing different package versions in different directories and appending the version number to the package name. A different method is used in Python. Tools such as Pip can be used to construct and manage deployments such that only one package version is installed. However, those methods are not easily transferable to relational databases. Generally, database systems do not support different object versions.

[0005] Different projects may run with different object versions and different language settings or options, which can cause library interference or malfunction. Database systems have different characteristics that are not typically found in programming - language ecosystems, such as:

[0006] · Schemata: Database objects are always created in a specific schema. If no schema is explicitly specified when creating an object, then it is created in the schema of the current user account. When both the object name and the schema are specified, the database object is fully qualified. If an object is not fully qualified in an SQL query, then the query optimizer will need to resolve it. Thus, if executed by different user accounts, such as when there are different versions of objects with the same name but in different schemas, then the same query with an un - fully - qualified object reference may result in different outcomes. This poses technical challenges such as where to deploy the source code and, once deployed, how to share the source code.

[0007] · Privileges: The database system implements a rich privilege model. Compared with the typical file system privilege model, the granularity of the privilege model is much finer. There are read, create, execute, drop, and alter permissions at the system-wide, system-schema, user-schema, and individual database object levels. In addition to the question of where to store the source code, there is also the question of whether and how to protect access to the source code and what privileges the source code can exercise. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the drawings:

[0009] Figure 1 is a block diagram depicting an example computer system for processing a data definition language (DDL) statement that uploads an implementation of a new guest programming language to a database management system (DBMS);

[0010] Figure 2 is a flowchart depicting an example computer process for executing a DDL statement that uploads an implementation of a new guest programming language to the DBMS;

[0011] Figure 3 is a flowchart depicting an example computer process for adding and using a new guest programming language in the DBMS;

[0012] Figure 4 is a block diagram depicting an example DBMS for processing a single DDL statement that results in generating a guest module containing multiple guest subroutines for a guest programming language;

[0013] Figure 5 is a flowchart depicting an example single DDL statement that results in the DBMS generating a guest module containing multiple guest subroutines for a guest programming language;

[0014] Figure 6 is a flowchart depicting some example lifecycle activities of a guest module and guest subroutines;

[0015] Figure 7 is a block diagram depicting an example DBMS for processing a request for a guest programming language to import dependencies, which results in the DBMS providing a guest module based on a mapping;

[0016] Figure 8 is a flowchart depicting processing a request for a guest programming language to import dependencies, which results in the DBMS providing a guest module based on a mapping;

[0017] Figure 9 is a flowchart depicting some example activities at the boundaries of database components such as database sessions, data manipulation language (DML) statements, and guest modules;

[0018] Figure 10 is a flowchart depicting some example activities for satisfying dependencies;

[0019] Figure 11 is a block diagram depicting an example DBMS having a multilingual engine (MLE) that facilitates cooperation between different guest programming languages;

[0020] Figure 12 is a flowchart depicting some example activities for accessing guest objects in a guest programming language from different guest programming languages;

[0021] Figure 13 is a block diagram depicting an example DBMS having guest virtual environments that provide alternative bindings of identically named dependencies to different guest modules;

[0022] Figure 14 is a flowchart depicting some example activities for generating, modifying, and using guest virtual environments that symbolically bind guest dependencies to guest modules;

[0023] Figure 15 is a flowchart depicting some example activities for sharing guest virtual environments among multiple database users and multiple guest programming languages, such as in a multi-tenant environment, such as cooperating or isolating (i.e., not cooperating) multiple database applications, such as in a private cloud of an enterprise;

[0024] Figure 16 is a block diagram depicting an example DBMS that transparently retrieves resources from a virtual file system to generalize alternative storage mechanisms;

[0025] Figure 17 is a flowchart depicting some example activities for a DBMS to retrieve resources from a virtualized storage device such as a virtual file system;

[0026] Figure 18 is a block diagram illustrating a computer system on which embodiments of the present invention may be implemented;

[0027] Figure 19 is a block diagram illustrating a basic software system that may be used to control the operation of a computing system. Detailed Description

[0028] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the present invention.

[0029] General Overview

[0030] The method of the present disclosure facilitates access to, for example, data manipulation language (DML), (e.g., custom) guest objects such as stored procedures and user-defined functions, which are written in modern programming languages such as JavaScript and Python. In an embodiment, all programming language source code is executed by the same high-performance engine called GraalVM. For example, the guest programming language may have an implementation based on the Truffle framework. GraalVM executes those guest programming languages within the address space of a database management system (DBMS) for maximum efficiency and performance, but runs the source code sandboxed such that unauthorized memory access or system calls are not possible.

[0031] Deploying guest source code to the database occurs via user-defined packages called guest modules. Each guest module is associated with a single guest programming language, and the content and structure of the guest module are specific to that guest programming language. Guest objects (such as the logic within a guest module) can be accessed in various ways, such as:

[0032] · Subroutines defined by a guest module can be called from DML (such as PL / SQL) via a call specification.

[0033] · A guest module can be imported by another guest module in the same guest programming language using a language-specific import mechanism.

[0034] · A guest module can be imported by another guest module in the same or a different guest programming language using an application programming interface (API) implemented by the multilingual engine (MLE) of the DBMS, which facilitates subroutines in the imported module to be called directly from the importing module.

[0035] An example MLE architecture for executing guest subroutines based on guest modules is presented herein. The MLE can execute stored procedures or user-defined functions (UDFs) in programming languages other than PL / SQL, such as dynamic languages (such as JavaScript, Ruby, Python, and / or R). The MLE is not limited to the execution of dynamic languages, as it can also run more or less static languages such as Java.

[0036] The MLE can include several layers. The top layer can implement the guest programming language(s). Each guest programming language implementation running on the MLE can be based on Oracle Truffle. Truffle is a language implementation framework for building high-performance abstract syntax tree (AST) interpreters that run on virtual machines (VMs) such as the Java VM (JVM). Each node in the Truffle AST has an execution method where it executes its child nodes and returns its own result, such as for partial evaluation. The main advantage of the Truffle AST interpreter is that it self-optimizes by using profiling information and partial evaluation.

[0037] Those profiles are collected during the execution of the guest language program. Significant optimizations can include type specialization, rewriting indirect function calls, polymorphic inline caching, branch elimination, and speculative function inlining, such as discussed herein. If a speculative hypothesis is proven false, then the specialized AST can be restored to a more general version, which provides functionality for more general cases.

[0038] When the execution count of a Truffle node reaches a predefined threshold, Truffle triggers partial evaluation by a call to Graal. Graal is a dynamic compiler that forms another layer of the MLE. Graal can be the just-in-time compiler (JIT) of the MLE, which can perform partial evaluation of parts of the AST, which may require Futamura projections as discussed herein. The output of Graal can be highly optimized machine code with deoptimization points. Those points can be implemented as checkpoints where, if a speculative hypothesis no longer holds, then deoptimization must be triggered. Deoptimization means that control transfers from the compiled code back to the AST interpreter, and then the specialized AST nodes are restored to a more general version.

[0039] Another layer of the MLE is the VM. For example, the MLE can use Oracle's Substrate VM (SVM), which is an embeddable VM that provides services such as code caching or garbage collection. The MLE can use the same VM for all language implementations included in the MLE.

[0040] One goal can be to provide future scalability without code changes. The MLE can provide pluggable post-sale language approaches, such as for general-purpose languages, legacy languages, and / or domain-specific languages (DSLs). For example, a customer who has implemented its own guest programming language on top of the Truffle framework can insert that language into the MLE according to the API provided by the MLE, which can be done without code changes to the MLE and the DBMS. The MLE provides a unified way to deploy and manage units of code libraries, such as packages and modules.

[0041] A guest module is a unit of logic (e.g., source) deployed into a database. Each guest module is implemented in a single corresponding guest programming language. The content and structure of a guest module can be specific to that guest programming language. New data definition language (DDL) statements are used herein to deploy source logic as one or more guest modules into a database.

[0042] MLE extensions, such as guest modules and guest virtual environments, are provided herein that allow all guest programming languages to share the same infrastructure for activities such as storage and lookup. Additionally, database privileges can be used to control access to such components. MLE can also include virtual file systems, with which source logic such as guest scripts can be distributed across several files in a nested directory structure, which can be bundled together and stored in a container format such as a zip file. Such source packages can be provided as binary large objects (BLOBs) or files and provided to MLE, such as via DDL statements.

[0043] MLE provides an architecture for in-language and inter-language module import. A guest virtual environment can provide a mapping between a module name and the schema object holding the module content. That mechanism can hide differences in module / package import specifications for different guest programming languages. The ability to import other guest modules provides several benefits:

[0044] · The ability to separate source logic into several independent modules.

[0045] · Reusability of source logic. By breaking code into modules, certain modules can be reused. Libraries can be provided as separate guest modules and imported by other guest modules belonging to different projects. Thus, each guest module can have a more or less independent maintenance schedule, such as according to the software development life cycle (SDLC).

[0046] · Ease of patching. Without inter-module import, redeployment of a monolithic (i.e., large) guest module would be required, but only a small portion of the underlying source code needs to be changed. By partitioning code into small guest modules, only a subset of the modules needs to be redeployed. MLE can also provide built-in modules, such as a structured query language (SQL) driver.

[0047] The import mechanism(s) for a guest programming language can have logic to consult the environment when loading a module. For example, for JavaScript, modules are imported via a require statement, and MLE can intercept and specifically handle that statement, including resolving dependent module names via the environment. Similar techniques are extended to other guest programming languages, such as Python.

[0048] The language-agnostic mechanism for the guest module and guest virtual environment presents a unified API for the management of source logic inside the database. This leaves a great deal of freedom for tooling deployment, which can adapt to the specific needs of the programming language ecosystem. For example, version resolution can be left more or less to the client-side tool, and the resolved version is mapped using the guest virtual environment within the database.

[0049] In an embodiment, the computer inserts the implementation of the guest programming language into the deployment of the DBMS. DDL statements are executed to register the guest programming language in the DBMS. The guest programming language is invoked in the DBMS by executing DML statements.

[0050] In an embodiment, a single DDL statement is executed to define multiple subroutines for the guest programming language in the DBMS. A second DDL statement registers a particular subroutine as a user-defined function (UDF) or stored procedure in the DBMS, and these functions or procedures can be invoked by DML statements.

[0051] In an embodiment, a DML statement invokes the guest programming language to cause: the execution of an import request native to the guest programming language to access dependencies, and the resolution of dependencies based on: the import request native to the guest programming language, and the mapping defined in the DBMS. As discussed later herein, defining an object in the DBMS may require storing the data and / or metadata of the object into the database schema and / or database dictionary in the DBMS or the database of the DBMS, where the metadata defines the characteristics, features, or configuration of the object.

[0052] An embodiment defines a guest object implemented in a first guest programming language in the DBMS. The DBMS includes: a native data manipulation language (DML), a first guest programming language, and a second guest programming language. The second guest programming language is invoked from the native DML, thereby causing an access request to be executed according to the second guest programming language to access the guest object implemented in the first guest programming language.

[0053] In an embodiment, a first DDL statement generates a guest virtual environment in the DBMS. A second DDL statement adds the binding of dependencies to the guest virtual environment. The guest programming language issues a request to access the dependencies. Based on the request and the binding, the guest module is accessed.

[0054] In an embodiment, a DML statement invokes the guest programming language to cause:

[0055] · the execution of a request native to the guest programming language to access dependencies, and

[0056] · Retrieving dependencies from a virtual file system with multiple alternative implementation mechanisms, the multiple alternative implementation mechanisms including: a first implementation mechanism based on an archive file or an actual file system, and a second implementation mechanism based on a memory buffer or columns of a database table.

[0057] 1.0 Example Computer System

[0058] Figure 1 is a block diagram depicting an example computer system 100 in an embodiment. A data definition language (DDL) statement 181 uploads an implementation of a new guest programming language to a database management system (DBMS) 110. The computer system 100 includes one or more computers, such as 190, each of which can be a rack server like a blade, a personal computer, a mainframe, a virtual computer, or other computing devices. When the computer system 100 includes multiple computers, the computers are interconnected via a communication network.

[0059] The computer system 100 includes a DBMS 110 that can be hosted by the computer 190, a different computer (not shown), or multiple computers for a distributed and / or multi-instance database. The DBMS 110 supports a multi-language (i.e., multilingual) programmable database, such as having a multi-language engine (MLE) software layer that can be embedded for multiple guest programming languages, corresponding interpreters, and / or virtual machines, such as a Java virtual machine (JVM), a JavaScript interpreter, which can be used alone or in combination, such as in Oracle's Graal MLE. For example, the MLE can interpret text scripts, generate bytecode, interpret bytecode, and / or compile bytecode into native machine instructions, such as through just-in-time (JIT) compilation. For example, the MLE can include a JVM that executes bytecode generated from source logic of multiple guest programming languages.

[0060] The DBMS 110 can be extended by adding guest programming languages (such as 140) that are not native to the DBMS 110. The guest programming language 140 can be added after it is put on the market for use in the DBMS 110, such as a general-purpose programming (e.g., scripting) language or a domain-specific language (DSL). For example, the guest programming language 140 does not initially need to be provided with the DBMS 110 and does not need to be obtained from the original equipment manufacturer (OEM) of the DBMS 110 (e.g., an independent software vendor, ISV).

[0061] The addition of the guest programming language 140 is performed by a data definition language (DDL) statement 181. For example, the DDL can be a proprietary language or an administrative dialect of a database language, such as the structured query language (SQL) native to the DBMS 110. The DDL generally writes metadata to the DBMS 110, such as in a database schema and / or database dictionary in the database in the DBMS 110, as discussed later in this document. Native database languages such as SQL are initially built into the DBMS 110 and do not need to be separately added to the DBMS 110 as required for the guest programming language 140. In an embodiment, the DDL statement 181 can be "CREATE MLE LANGUAGE MYLANGUAGE;", where MYLANGUAGE is the name identifying the guest programming language 140.

[0062] The DBMS 110 can receive the DDL statement 181 from a client, such as from an ad-hoc database tool or other software application, such as text connected with open database connectivity (ODBC), which may require interprocess communication or networking, such as when the computer 190 is a remote client. In another scenario, the DDL statement 181 is generated internally by the DBMS 110. The execution of the DDL statement 181 more or less fully adds the guest programming language 140 to the DBMS 110.

[0063] For example, the guest programming language 140 can be based on implementation files, such as 150, such as class files and / or resource files, which can be loose files and / or bundled into an archive file such as a Java archive (JAR) file. In an embodiment, the implementation file 150 can contain: a) a grammar 162 that formally defines the syntax of the guest programming language 140, such as for tokenization and / or parsing, and / or b) a parser 161, also for parsing, such as based on the grammar 162, such as for constructing a parse tree (not shown). In an embodiment, different guest programming languages can each have their own corresponding grammar, such as 162, but share the same parser 161. Other (e.g., sharable) language components can include a semantic analyzer, an optimizer, a (e.g., intermediate or machine) code generator, and / or a linker or loader that locates cross-referenced resources. For example, Graal provides many components that can be shared and / or customized, such as a collaborative compiler / interpreter layer, such as Truffle as the front end and Substrate as the back end.

[0064] In an embodiment, an implementation file of the guest programming language 140 is staged (i.e., placed), for example, manually, into a code library or other file system of the DBMS 110, such as before the DDL statement 181 is submitted, such as by a database administrator (DBA), a system administrator, or a user with access to the command shell and / or file system of the computer hosting the DBMS 110. In another embodiment, the execution of the DDL statement 181 automatically causes the implementation file to be staged into the DBMS 110, which may require copying the implementation file within the same file system, copying the implementation file between multiple file systems, (symbolic) linking of files, or uploading the implementation file from a remote client. For example, a remote client can use a Java Open Database Connectivity (JDBC) driver including the Hypertext Transfer Protocol (HTTP) or Java Remote Method Protocol (JRMP) for uploading one or more files from the remote client to a subsystem of the DBMS 110, such as a Common Gateway Interface (CGI), such as by HTTP POST. For example, the DDL statement 181 can include a Uniform Resource Locator (URL) of a JAR file that contains an embeddable implementation (e.g., interpreter) of the guest programming language 140.

[0065] The execution of the DDL statement 181 causes the guest programming language 140 to be registered (e.g., publicly) in the database dictionary 120 or other metadata repository that is part of the DBMS 110. The database dictionary 120 includes metadata that defines the database objects and other configuration aspects of the DBMS 110. The database dictionary 120 can include multiple data structures for storing database metadata. For example, the database dictionary 120 can include multiple files and tables. Portions of the data structures can be cached in the main memory of the database server of the DBMS 110.

[0066] A subset of the metadata that defines a particular database object of the DBMS 110 or a particular aspect of the configuration of the DBMS 110 is referred to herein as a metadata definition or simply a definition. A definition can also include multiple data structures and tables. The definition of a particular database object can include the definitions of the components that make up the data object. For example, the definition of a table can include multiple definitions of the columns of that table.

[0067] The metadata in the database dictionary 120 that defines a procedure can specify the name of the procedure, the arguments of the procedure, the return data type, and the data types of the arguments, and can include the source code and its compiled version. A database object can be defined by the database dictionary 120, but the metadata in the database dictionary 120 itself can only partially specify the characteristics of the database object. Other characteristics can be defined by data structures that may not be considered part of the database dictionary 120. For example, as discussed later in this document, a user-defined function (UDF) implemented in a Java class can be partially defined by the database dictionary 120 by specifying the name of the user's Java function and by specifying references to the compiled versions (i.e., bytecode) of the files containing the source code of the Java class (i.e., the .java file) and the class (i.e., the .class file).

[0068] A binding can be a definition that is directly associated with another object in the database dictionary 120, such as a name. For example, the database dictionary 120 can contain key-value pairs, such as in a lookup table or a hash table. For example, the database dictionary 120 can be an implementation of a database namespace, and / or can contain database objects such as a relational schema. DDL statements can be used to write definitions and / or bindings to the database dictionary 120 or the database schema.

[0069] Entries in the data dictionary 120 can be accessed via a retrieval key such as name 130. The object (i.e., the value) can be stored directly in the content storage space of the database dictionary 120, or indirectly via a reference, such as a pointer to a memory location storing an object outside the database dictionary 120. Thus, components shown as being inside the database dictionary 120, such as the guest programming language 140, can actually reside elsewhere in the memory of the DBMS 110 and are instead referenced by corresponding entries (e.g., key-value pairs) in the database dictionary 120.

[0070] The name 130 can be the same as the language name that appears in the DDL statement 181, such as MYLANGUAGE, as explained above. For example, the DDL statement 181 can immediately cause the guest programming language 140 to be generated in the memory of the DBMS 110, such as by executing initialization logic from a staging implementation file of the guest programming language 140. In an embodiment, the memory initialization for the guest programming language 140 can occur lazily, such as on a later request, such as when the name 130 is later used to access the guest programming language 140. Regardless of whether the initialization of the guest programming language 140 is lazy or eager, the name 130 is immediately bound by the DDL statement 181 to the guest programming language 140 in the database dictionary 120.

[0071] Subsequently, the DBMS 110 can receive or generate Data Manipulation Language (DML) statements 182, such as database queries, which cause logic to execute within the guest programming language 140. For example, the DML can be a proprietary language or a data access dialect of a database language, such as SQL native to the DBMS 110. The DML is designed to create, read (e.g., query), update, and delete (CRUD) ordinary data in the database of the DBMS 110. While the DDL is designed to write (i.e., create, update, and delete), but for metadata (i.e., definitions) rather than database data. Query By Example (QBE) (e.g., JavaScript Object Notation, JSON) and path expressions (e.g., XPath) can be examples of DML, in whole or in part.

[0072] The DML statement 182 can include a textual reference (e.g., name) of a database object defined in the DBMS 110. The DBMS 110 can use the database dictionary 120 or the database schema to resolve those names to actual database objects, such as user-defined functions (UDFs). Some database objects can be generated (i.e., defined) only by executing SQL statements. Other database objects are instead generated in the guest programming language 140. Thus, some database objects are also guest objects.

[0073] As described later herein, and in some cases facilitated by bindings in a database dictionary, for example, a guest object can be bound to a database object that is not a guest object. For example, the DML statement 182 can explicitly call a stored procedure or UDF that is a database object, which, although not a guest object, is actually implemented as (i.e., bound to) a guest object, such as a subroutine 170 in the guest programming language 140.

[0074] For example, the subroutine 170 can be a separate Python function, or an entire imperative script in Python, which is exposed as a stored procedure or UDF explicitly called by the DML statement 182. In an embodiment not shown, the database dictionary 120 contains the declaration or definition of that stored procedure or UDF for inspection by a query planner such as the DBMS 110. Mechanisms and techniques for operating across the language boundary between the native DML statement 182 and the guest subroutine 170 will be discussed later.

[0075] As discussed above, the guest programming language 140 can be implemented in the DBMS 110 with components and / or layers dedicated to specific (e.g., compilation) activities such as optimization, such as Truffle and Substrate. Accordingly, the execution of guest subroutines 170 can be accelerated according to various statistical and / or incremental techniques such as: a) Futamura projection, b) just-in-time compilation (JIT) of only a portion of subroutine 170, and / or c) generation of speculative code with one or more deoptimization points. The speculative logic performs static or dynamic (e.g., profiling) optimization based on the inferred (e.g., observed) data type of polymorphic variables.

[0076] Deoptimization points demark segments of the generated code that become invalid due to unexpected data types and should immediately be replaced with less optimized (e.g., earlier) code. Partial JIT can transform hot (i.e., repeated more than a threshold) segments of subroutine 170, such as tight loops, such as by loop unrolling. As discussed later herein, Futamura projection is an architectural transformation that can include partial evaluation (i.e., logical specialization), memoization (i.e., a function result cache typically with a composite key containing the name or pointer of the function and its actual argument values), and / or strength reduction (i.e., semantic restructuring; e.g., a) hotspots with loop invariants and / or induction variables, or b) arithmetic operation replacement).

[0077] Substrate can apply Futamura projection, such as ahead-of-time (AOT) code generation. For example, a DDL statement 181 can eagerly (e.g., immediately) cause AOT code (e.g., low priority) to be generated in the background for some or all of the subroutines 170, even though subroutine 170 may not be called first (e.g., by a DML statement 182) until much later. Thus, an engineer expecting a clumsy interpretation of the script can instead obtain machine language for direct execution that is highly optimized for a particular version of a particular central processing unit (CPU) model, such as in a production environment that was unknown or unavailable during application development.

[0078] 2.0 Example Language Deployment Process

[0079] Figure 2 is a flowchart depicting the computer system 100 in an embodiment adding a new guest programming language 140 to the DBMS 110. Refer to Figure 1 discussion Figure 2 。

[0080] Depending on the embodiment, steps 202 and 204 may or may not be combined into a single step. In an embodiment, step 202 may be fully, partially, or not at all implemented by the DBMS 110 itself. For example, the automation required to perform step 202 may be implemented elsewhere in the computer system 100 and may or may not require manual labor by a system administrator such as a database administrator (DBA).

[0081] Step 202 inserts an implementation of the guest programming language 140 into the deployment of the DBMS 110. For example, the DBMS 110 may have a library path, such as an ordered list of file system folder paths, that identifies where the DBMS 110 can find extensions to its own code base (e.g., aftermarket), such as the code base for an implementation of the guest programming language 140, which may consist of loose or packaged files. Automation or an administrator may stage (i.e., copy in place) the (one or more) code library files of the guest programming language 140 into the library path of the DBMS 110. Depending on the implementation of the DBMS 110, the DBMS 110 may or may not need to be restarted to prepare the DBMS 110 to load (e.g., dynamically link) the staged code library of the guest programming language 140.

[0082] In step 204, a DDL statement 181 is executed to register the guest programming language 140 in the DBMS 110. For example, a database client script or an autonomous client may send the DDL statement 181 from the computer 190 to the DBMS 110, which may be on the same or different computer(s) (e.g., via ODBC). Depending on the embodiment, the DDL statement 181 may identify any of the following: a) the name 130 of the guest programming language 140, such as a naming key to be inserted into the database dictionary 120, and / or b) the code library path and / or class name of the implementation of the guest programming language 140.

[0083] Execution of the DDL statement 181 causes the multi-lingual engine (MLE) of the DBMS 110 to instantiate a memory data structure implementing the guest programming language 140, which may require class loading or script execution from the staged code library of the guest programming language 140. In an embodiment, the DDL statement 181 may also perform step 202 (i.e., combined with step 204).

[0084] For example, the DDL statement 181 may include a uniform resource locator (URL) or a cross-mounted path that locates an implementation of the guest programming language 140 that does not yet need to be staged into the DBMS 110. Staging may occur automatically based on a push or pull mechanism as appropriate for deployment to a public cloud that may deny the client direct access to the file system of the DBMS 110, such as via a remote shell.

[0085] In a pull embodiment, the DBMS 110 can process a URL to automatically upload a code library of the guest programming language 140 and stage it for deployment in the DBMS 110. That embodiment can require a web server or file server running on the host pointed to by the URL, which may or may not be the computer 190.

[0086] In a push embodiment, the client (e.g., ODBC) driver has additional logic to upload the code library file into the DBMS 110. Depending on the embodiment, the upload can be multiplexed through the driver's database connection, and the DBMS 110 can save the upload to its own code library, or the driver can use a separate network connection, such as for a Common Gateway Interface (CGI) POST to a web server, which can save the upload to the DBMS 110's code library. For example, the DBMS 110 can include a web server (not shown).

[0087] After step 204, the guest programming language 140 is ready to be used in the DBMS 110. Step 206 executes a DML statement 182 that invokes the guest programming language 140 in the DBMS 110. For example, as presented later herein, the DBA can export a subroutine of the guest programming language 140 as a UDF that can be called by the DML statement 182. Thus, the guest programming language 140 can be indirectly used for DML queries without exposing the client to the guest programming language 140. For example, a legacy query can call a complex UDF that was initially implemented as a suboptimal DML and was ultimately transparently improved (e.g., re-implemented and accelerated) by the guest programming language 140.

[0088] 3.0 Example Language Management

[0089] Figure 3 is a flowchart depicting the computer system 100 adding and using a new guest programming language 140 in the DBMS 110 in an embodiment. Refer to Figure 1 Discussion Figure 3 。

[0090] Step 301-302 facilitates the deployment of guest programming language 140 into a public cloud (not shown), as described below. As discussed above, DBMS 110 includes (one or more) server computers that may or may not include client computer 190. For example, client computer 190 may be separate from DBMS 110 and host client software that operates as a remote client of DBMS 110, such as using ODBC. For example, client computer 190 may be separate from the public cloud hosting DBMS 110. Thus in step 301, DBMS 110 remotely receives DDL statement 181 from client computer 190.

[0091] Step 302 uploads (one or more) code library files 150 for the guest programming language, which may occur automatically during the processing of DDL statement 181. Various techniques for pushing or pulling (one or more) uploaded files 150 were discussed earlier in this document.

[0092] Steps 303-304 require configuration metadata (not shown) for guest programming language 140 that is recorded in database dictionary 120. Step 303 binds the name 130 of guest programming language 140 to the (e.g., partially) linked / loaded implementation of guest programming language 140. For example, such an implementation may be based on code library file 150. Linking, loading, and registration within database dictionary 120 are discussed elsewhere in this document.

[0093] Step 304 uses the configuration metadata in database dictionary 120 to call guest subroutine 170. As discussed later in this document, such metadata may be a call specification that wraps guest subroutine 170 for invocation from DML statement 182 as a stored procedure or UDF. Also as discussed later in this document, another DDL statement (not shown) may generate such metadata.

[0094] Step 304 may result in one, some, or all of steps 305-307 of dynamic (re)optimization logic. As explained earlier in this document, guest programming language 140 may be an interpreted (e.g., scripting) language such as Python, R, JavaScript, Ruby, Pig, or (e.g., Java) intermediate bytecode, all of which generally require an interpreter in order to execute. For example, (one or more) code library files 150 may implement that interpreter. In an embodiment such as using Truffle, the interpreter itself undergoes dynamic analysis such as partial evaluation and other interpretation, specialization and other (e.g., speculative) optimizations, and JIT compilation.

[0095] Accordingly, the interpreter itself can vary / evolve in an optimal direction for a specific guest subroutine 170 and / or a specific DML statement 182 that invokes the guest subroutine 170. This interpreter improvement that adapts to specific customer logic is called Futamura projection, which has several progressive degrees (i.e., projections) along a spectrum of intensity, from optimizing the interpreter at one end of the spectrum to reshaping the optimized interpreter into a compiler, or at the other end of the spectrum, optimizing the compiler. Step 305 performs at least a first-degree Futamura projection (i.e., interpreter optimization). The efficiency of Futamura projection can depend on a large number of repeated invocations of the guest subroutine 170 to amortize the optimization overhead (e.g., initial latency). For example, the guest subroutine 170 can be invoked for each of thousands or millions of rows of a database table during execution of the same DML statement 182.

[0096] Step 306 partially evaluates the guest subroutine 170. For example, the DBMS 110 can optimize all or some (e.g., subtrees) of the AST of the guest subroutine 170. For example, tight loops within the guest subroutine 170 can be isolated for semantic optimization on their own, while the remainder of the guest subroutine 170 undergoes ongoing interpretation without optimization. Similarly, JIT compilation can be applied to all or some of the AST.

[0097] Step 307 generates speculative logic representing some or all of the guest subroutine 170 based on more or less fragile assumptions, such as data type inference, such as based on dynamic profiling of the guest subroutine 170. The speculative logic can include (one or more) guards that dynamically verify such assumptions. For example, a guard can detect a failed (i.e., violated) assumption and react by restoring logic at (one or more) deoptimization points, including falling back to unoptimized logic that does not require such assumptions, such as logic that was previously used and is still in the cache.

[0098] 4.0 Guest Module

[0099] Figure 4 is a block diagram depicting an example DBMS 400 in an embodiment. A single DDL statement 441 causes the DBMS 400 to generate a guest module 461 containing multiple guest subroutines 471 - 472 for a guest programming language 420. The DBMS 400 can be an implementation of the DBMS 110.

[0100] The language modules, such as 461-463, are administrative and / or lexical (i.e., scope / visibility) units that define one or more objects, such as subroutines 471-472, which are native to the guest programming language 420 and are available for external (e.g., public) access from outside the guest module 461. The guest module 461 can contain other objects, depending on the embodiment, which are: a) also publicly accessible but not subroutines, such as global variables, such as data structures, b) accessible only from within the guest module 461, or c) accessible only within the guest programming language 420.

[0101] In an embodiment, the DDL statement 441 can be "CREATE MLE MODULE scott.'jsmodule' LANGUAGE JAVASCRIPT AS module.exports.func=function(){...};", details as follows. JAVASCRIPT is the name 452 of the guest programming language 420 for which the guest module 461 is created. The name of the guest module 461 is jsmodule, shown as name 451.

[0102] When created, the guest module 461 is registered within a database schema (not shown). If the name 451 is unqualified in the DDL statement 441, then the guest module 461 is registered within the default (e.g., current, global, and / or system) schema. If the name has a qualifier, such as scott, then the guest module 461 is instead registered within the existing schema named scott. For example, the database dictionary 410 can be used for schemas such as scott or default, and the database dictionary 410 can contain names 451-455 as retrieval keys. Since schemas act as namespaces, modules in different schemas can have the same unqualified name but different qualifiers.

[0103] As occurs in the example DDL statement 441 above, the new module exports (i.e., makes public) a single object named "func", which in this case happens to be: a) an anonymous (i.e., without a guest-native name) JavaScript object, b) a function, and c) inline-defined (i.e., directly as JavaScript within the DDL statement 441). The export clause can export multiple objects, such as "AS module.exports.A=function(){} module.exports.B=function(){}", where spaces act as delimiters.

[0104] The above example DDL statement 441 is a detailed (i.e., self - contained) form of the module creation statement because the exported object(s) are defined inline. The module creation statement can alternatively be in other forms that define the exported object(s) by reference. The following is an example syntax for the module creation statement.

[0105]

[0106] In the above syntax, the USING clause is an alternative to the AS inline clause. The BFILE item can specify a file path or a resource URL, such as a JAR URL, such as for guest language materials, i.e., remotely available, bundled in an archive file, and / or dynamic (e.g., HTTP CGI) content. The Binary Large Object (BLOB) or Character (i.e., text) Large Object (CLOB) item can specify a DML (e.g., SQL) select clause that retrieves content from a single column of a single row of a relational table or result set. For example, the DBMS 400 can be a Relational DBMS (RDBMS) that maintains a table in the database that stores the corresponding JavaScript object in each row of the same column.

[0107] Depending on the embodiment, the VERSION item can be used for compatibility checking and / or for exposing multiple versions of the same module with the same name 451. The ENV item specifies the language programming environment, as explained later in this document.

[0108] In an embodiment, after the DDL statement 441 creates the guest module 461 in the guest programming language 420, the guest subroutines 471 - 472 are immediately available in some but not all of the following contexts. At this time, using the newly created guest module 461, the guest subroutines 471 - 472 may not yet be declared in important components of the DBMS 400, such as the database dictionary 410, including relational algebra mechanisms such as DML parsing and query planning and guest programming languages other than 420. Depending on the embodiment, the guest subroutines 471 - 472 may be completely unavailable at this time, or only visible for a specific combination (e.g., all) of the guest programming language 420, the guest module 461, and / or the current guest user virtual environment (ENV), as discussed later in this document.

[0109] Thus, after creating the guest module 461, exposing the guest subroutines 471-472 requires creating a corresponding calling convention, such as 480. The calling convention 480 is metadata in the database dictionary 410 that is defined as the inter-language binding used by other languages such as DML and / or (e.g., different) guest programming languages. The calling convention 480 can be used for: a) parsing the (e.g., DML) calls of the subroutine 472, including signature overloading, b) converting the data types of the (one or more) inputs and / or (one or more) outputs of the guest subroutine 472, c) acting as a placeholder or proxy operation for the guest subroutine 472, such as in a planned or parsed query tree, and / or d) actually calling (i.e., transferring the control flow to) the guest subroutine 472. Thus, the calling convention 480 can sometimes act as a passive descriptor operation for the guest subroutine 472, while other times as an active mediator (i.e., glue logic) between the guest subroutine 472 and its caller.

[0110] The DDL statement 442 creates the calling convention 480. In an embodiment, the DDL statement 442 can be "CREATE OR REPLACE FUNCTION function472 RETURN VARCHAR2 AS MLE MODULE jsmodule SIGNATURE'subroutine472(str1 string,str2 string)';" with details as follows. The name of the guest module 461 is jsmodule, shown as name 451. The name of the guest subroutine 472 is subroutine472. The guest subroutine 472 is exposed (e.g., renamed for conflict or backward compatibility) as function 472. The guest subroutine 472 has a signature that accepts two string parameters (i.e., the string type native to the guest programming language 420) and returns a string (i.e., the string type native to the DML language). Execution of the DDL statement 442 makes the visibility of the calling convention 480 and the callability of the guest subroutine 472 available anywhere the guest module 461 is available, such as DML and guest programming languages other than 420.

[0111] Guest modules (such as 461-463) are composable and can depend on each other as follows. For example, the guest module 462 can expose (i.e., export) an object used by the guest module 461. For example, the guest subroutine 471 in the guest module 461 can import (and e.g., call) a guest subroutine (not shown) provided by the guest module 462.

[0112] The techniques herein strive for flexibility and reuse, despite complexity (such as backward compatibility and isolation, such as for multi-tenancy and / or library versioning). Accordingly, the mutually dependent guest modules 461 - 463 are only loosely (i.e., symbolically) coupled to the names 453 - 455, as follows. Each guest module can rename (i.e., define its own name) the dependencies (i.e., other guest modules that are imported (i.e., cross-referenced)).

[0113] For example, guest module 462 is referred to as name 453 within guest module 461, which need not be the original name of guest module 462. For example, guest subroutine 471 can be defined in a Python script that has an import statement that states (i.e., cross-references) a binding to name 453 of guest module 462. However, a different guest module (such as 463) can import the same guest module 462 under a different name, or can have a different guest module bound to the same name 453.

[0114] Accordingly, name 453 operates as an alias. In an embodiment, aliases can be cascaded. For example, within guest module 461, names 454 - 455 are synonyms because name 455 is bound to name 454. For example, a Python script can use either name 454 or 455 to refer to guest module 463.

[0115] The guest programming language 420 can instead be Java, which can have classes instead of scripts. The activities of script execution discussed herein can instead occur during class loading and / or class execution. In an embodiment, each Java guest module is implemented as a native Java module, such as a Java-9 module, an OpenJDK Jigsaw module, or an Open Service Gateway Initiative (OSGi) module. Each Java module has its own descriptor classes that cross-reference other modules as dependencies. Except for OSGi, loading one Java module among many mutually dependent Java modules causes eager loading of the transitive closure of cross-referenced descriptor classes. Loading other implementation (e.g., helper) classes from a Java module can rely on natural class loading semantics, which are mostly or entirely lazy.

[0116] Regardless of how lazy the native module loading is implemented, embodiments of the DBMS 400 may or may not enforce eager resolution of guest modules, even if the guest module loading is more or less lazy. Module resolution requires mapping dependency names (i.e., aliases) to the actual module implementations. For example, an embodiment with lazy module resolution may create modules in any order by issuing DDL create statements in any order. However, eager module resolution may require that dependent modules be created before other modules that use those dependencies, thus prohibiting circular dependencies. For example, for eager module resolution, a DDL statement to create a module will fail if any of the dependency names for that module cannot be immediately resolved to other resolved modules. However, lazy module resolution may defer (e.g., fail) the resolution until the dependency is actually used. In either case, whether module resolution includes module loading (e.g., script execution) depends on the embodiment.

[0117] As discussed above, the modules 461-463 are defined within one or more database schemas (not shown), which naturally provides the following potentially important isolation. The guest object lifecycle and visibility may deviate from state-of-the-art guest language concepts, as follows. For example, the DBMS 400 may be multi-user, multi-role, multi-tenant, and access-controlled (e.g., DDL permission statements). Those complexities do not exist in a conventional JavaScript environment such as a web browser. However, the database schema provides substantial isolation by enforcing visibility at various granularities.

[0118] For example, each database application or application subsystem may have its own database schema that defines its own users, their roles, and their privileges. Since applications generally do not share schemas, those applications should not share modules either, as follows. Multiple applications may share the same codebase (e.g., scripts, libraries) of a module, and those applications may give the same alias to that module. However, since those applications have separate schemas, separate instances (i.e., copies) of that module should be loaded into the RAM of the DBMS 400 at runtime. For example, the guest module 461 may be one of many defined instances of the same module deployment. The DBMS 400 treats each instance of the same module deployment as a separate (i.e., independent) module.

[0119] Each instance for the same module deployment is initialized separately, which may require repeating the execution of the same codebase. For example, the module creation DDL statement 441 creates only one module instance in one database schema. The difference between a module instance and its codebase is as follows. The codebase of a module (not shown), such as a script or a library, may be the unit of deployment into the DBMS 400. For example, multiple instances of the same module may be created by repeating the execution of the module's script.

[0120] For example, another more or less similar DDL statement (not shown) can create another module instance of the same general module, but in a different schema. Both DDL statements can cause duplicate execution of the same module codebase. For example, both DDL statements can specify the same Python script or the same Java archive (JAR) as the module codebase, which can cause the script to run twice, or can cause the JAR to be loaded twice by two separate class loader instances. Thus, the two created module instances can have separate (i.e., independent) copies of nominally the same Python global variables or the same Java static fields.

[0121] 5.0 Example Module Creation Process

[0122] Figure 5 is a flow chart depicting a single DDL statement 441 that causes the DBMS 400 to generate a guest module 461 containing multiple guest subroutines 471 - 472 for a guest programming language 420. Refer to Figure 4 Discussion Figure 5 .

[0123] In the illustrated embodiment, preparation of the new guest subroutine 472 in the database dictionary 410 occurs in steps 502 and 504, and each of those steps executes the corresponding DDL statements 441 - 442 as follows. Step 502 executes DDL statement 441, which initiates a bulk load of multiple guest subroutines 471 - 472 to define them in the database dictionary 410. DDL statement 441 creates a new guest module 461 for the guest programming language 420 and binds the guest module 461 in the database dictionary 410 to the name 451 included in the DDL statement 441.

[0124] The DDL statement 441 directly or indirectly provides (e.g., customizes) a codebase that (e.g., textually) defines one or more guest subroutines 471 - 472. For example, the DDL statement 441 can contain a string (e.g., with reference and character escape encoding) that contains (e.g., Python) guest script statements that literally define the guest subroutines 471 - 472 inline. In another example, the DDL statement 441 references a Python script file containing those guest script statements via a URL or a path.

[0125] In any case, step 502 executes those guest script statements to cause the guest programming language 420 to internally define guest objects, such as subroutines 471-472. In an embodiment, only a subset of those new guest objects 471-472 is directly provided to the DBMS 400. For example, the DDL statement 441 and / or the guest script statements can declare which specific guest objects (or in an embodiment, which ones not) to export.

[0126] Exporting and selective exporting are discussed elsewhere herein. For example, the multi-lingual engine (MLE) of the DBMS 400 can have a corresponding export implementation based on the guest programming language 420. For example, the export can be directly supported in a more or less native way of the guest programming language 420, such as using Harmony (aka ECMAScript 6). Unfortunately, the export intrudes into the guest script statements, as explained elsewhere herein. Also as explained herein, the native module system of Java requires (e.g., hand-coded) classes to implement the export. However, other embodiments can appropriately separate concerns, such as export and scripting. For example, the MLE of the DBMS 400 can automatically generate boilerplate declarations for export, dependencies (i.e., imports) and / or other aspects of the module, module boundaries, and / or module composition (i.e., aggregation arrangements).

[0127] Embodiments of the present disclosure can separate the export and exposure of guest objects into different steps 502 and 504. As explained above, step 502 instantiates the guest subroutines 471-472 and exports them to the DBMS 400 and its MLE. However, in an embodiment, the export does not make the guest subroutines 471-472 available for calling from the DML statement 444, because the DML statement can only call UDFs and stored procedures, not arbitrary subroutines.

[0128] Step 504 executes the DDL statement 442 to generate a call specification 480 for the guest subroutine 472 and registers the call specification 480 in the database dictionary 410 for later reference by DML statements (such as 444). The generation of the call specification 480 has been discussed previously herein. In an embodiment not shown, there is no DDL statement 442 and no step 504, and call specifications are automatically (e.g., lazily) generated for all exported guest subroutines of the guest module 461, such as during the previous step 502.

[0129] Step 506 executes DML statement 444, which references call specification 480 to call guest subroutine 472, as explained earlier in this document, such as during a database query. Step 506 extracts call site information from DML statement 444, which can include the name of a UDF or stored procedure, which can be used as a lookup key to retrieve call specification 480 from database dictionary 410. Parameter ordering and data types can be inferred from the call site, such as for signature overloading and / or warning semantic errors, such as an incorrect number of arguments, a data type mismatch of an argument or return value, or an incorrect direction for an OUT argument. In an embodiment, call specification 480 can have OUT or IN / OUT arguments even when the guest programming language 420 natively does not support output arguments, such as when the MLE of DBMS 400 can generate or otherwise provide a data structure for marshaling the argument(s).

[0130] As explained elsewhere in this document, call specification 480 can convert the value of a return value or an argument between (e.g., somewhat similar) data types. Step 506 can repeatedly call guest subroutine 472 via call specification 480, such as for each of multiple database table rows and / or for each of multiple call sites. DML statement 444 can also call other call specifications for other guest subroutines (such as 471).

[0131] 6.0 Example Module Lifecycle Activities

[0132] Figure 6 is a flowchart depicting some of the lifecycle activities of guest module 461 and guest subroutines 471 - 472. Refer to Figure 4 Discussion Figure 6 。

[0133] Steps 601 - 605 illustrate activities that can occur during the initial deployment of guest module 461. Step 606 illustrates the maintenance (e.g., patching) of guest subroutines 471 - 472. Step 607 illustrates the use of guest subroutine 472.

[0134] The initial deployment of the guest module 461 may require the execution of a series of DDL statements, including the creation of the guest module by DDL statement 441 in steps 601 - 603, the management of the guest module by data control language (DCL) statement 443 in step 604, and the generation of call specifications by DDL statement 442 in step 605. In step 601, the DBMS 400 receives and begins to execute the DDL statement 441 to create the guest module 461 and the guest subroutines 471 - 472. Since instantiating the guest subroutines 471 - 472 requires the execution of the guest programming language 420, the DDL statement 441 should include the name 452 of the guest programming language 420, which step 601 can use as a lookup key in the database dictionary 410.

[0135] Step 602 creates the new guest module 461, which may require the execution of one or more scripts or one or more classes in the guest programming language 420. For example, the DDL statement 441 can include an inline script or can reference a script in a file.

[0136] Step 603 binds the name 451 to the new guest module 461 in the database dictionary 410, such as according to the database object definition techniques and mechanisms described elsewhere herein. The DDL statement 441 specifies the name 451. The database dictionary 410 and its association with a (e.g., user or default) database schema are discussed elsewhere herein.

[0137] Step 604 executes the DCL statement 443 to grant various permissions to various users and / or roles. For example, some users may be allowed to use but not revise the guest module 461. Also for example, some users may be prohibited from using the guest module 461.

[0138] Step 605 executes the DDL statement 442 to generate the call specification 480 for the guest subroutine 472. For the call specification 480, step 605 can generate or reuse the mapping of data types between the DML and the guest programming language 430, and can embed such mapping logic into the call specification 480. The call specification 480 can specify: argument types such as for parsing and / or overloading of signatures, parameter directions such as OUT, and / or indications of idempotency, cacheability, and / or thread safety (e.g., for optimization and / or parallelism).

[0139] Afterwards, one, some, or all of the guest subroutines 471-472 can be revised. Step 606 executes a single DDL statement (not shown), such as the ALTER MODULE statement presented elsewhere herein, to revise (i.e., replace) any or all of the guest subroutines 471-472. For example, the ALTER MODULE statement can specify a revised code library, such as inline or in a file. Step 606 replaces the guest subroutines 471-472 and preserves any call specifications that have already been generated, such as 480, but some or all such call specifications may need to be regenerated via additional DDL statements, such as for signature changes. In an embodiment, the call specification 480 is automatically regenerated during step 606.

[0140] Step 607 actually invokes the guest subroutine 472 during the execution of the DML statement 444. The guest subroutine 472 may require increased privileges to access resources, or may benefit from reduced privileges for security, such as to avoid accidental or malicious misuse. As presented later herein, the call specification 480 can state whether the guest subroutine 472 inherits the privileges of any user account that invokes the call specification 480, or whether the guest subroutine 472 should instead inherit the privileges of the administrative user account that defines the guest module 461.

[0141] That is, the call specification 480 specifies under which of the two user accounts the guest subroutine 472 should execute. Thus, as shown, when the guest subroutine 472 is invoked via the call specification 480, step 607 can switch to the user account of the module definer. When the guest subroutine 472 returns control to the execution of the DML statement 444, execution returns to the user account of the caller, which is the user who submitted the DML statement 444. The user account and the guest module boundary can be related to the execution context, which will be introduced later herein.

[0142] 7.0 Module Dependencies

[0143] Figure 7 is a block diagram depicting an example DBMS 700 in an embodiment. A native request 751 for importing a dependency 790 of the guest programming language 710 causes the DBMS 700 to provide a guest module 721 or 722 based on a mapping 780, as follows. The DBMS 700 can be an implementation of the DBMS 110.

[0144] Guest objects, such as exported subroutines, are defined in a guest programming language 710 of the DBMS 700, such as in a guest script 730 (e.g., Python). Although not shown, multiple guest objects may be distributed across one or more guest modules defined in the guest programming language 710. In operation, DML statements 771 - 773, such as SQL, may access the exported guest objects, such as in a database dictionary (not shown) of the DBMS 700.

[0145] For example, a guest module may have been defined based on a guest script 730 (e.g., Python) that defines one or more guest objects (i.e., exported), such as subroutines. Creation of those guest objects requires execution of the guest script 730, which occurs each time a guest module instance is deployed using the same guest module.

[0146] As explained, script execution creates guest objects. The lifecycle of a guest object depends on various implementations as follows. The lifespan of a guest object does not exceed that of the guest module that contains it.

[0147] The guest object lifecycle and visibility may deviate from state - of - the - art guest language concepts as follows. For example, the DBMS 700 may be multi - user, multi - role, multi - tenant, and access - controlled (e.g., DDL grant statements). Those complexities do not exist in a conventional JavaScript environment, such as a web browser. The DBMS 700 may have additional technical issues, such as database schemas as namespaces and multi - threading, which have visibility and sharing implications that are lacking in browser scripts. As discussed elsewhere herein, techniques such as guest modules and environments may provide some desired isolation. However, enterprise or cloud solutions may require more robust isolation for additional security (i.e., correctness, such as for security or compatibility), as follows.

[0148] In an embodiment, an execution context (not shown) is an additional mechanism that provides sufficient isolation. An execution context is a coarse - grained control - flow mechanism whose operating characteristics lie between lightweight threads and heavyweight processes of an operating system. Like threads, multiple execution contexts may share the same address space, such as the address space of the DBMS 700. Like heavyweight processes, an execution context may have its own private environment namespace from which resource dependencies may be resolved (i.e., looked up). An execution context may interoperate with database objects of the DBMS 700 as follows.

[0149] The DBMS 700 can have concurrent execution contexts, and each execution context is exclusive to a database session and is single-threaded. The execution context can have the same lifespan as its database session. At least when its database session is idle, the execution context can be idle. Thus, at any given time, only a fluctuating subset of the execution contexts can be active. For example, the total number of threads in a thread pool can be less than the number of execution contexts served by that pool.

[0150] In an embodiment, multiple execution contexts do not share guest module instances. For example, the same user can have two database sessions for the same database schema, which creates two guest module instances for the same guest module deployment. For example, for the same guest module deployment, a new guest module instance can be created for each execution context that uses that guest module deployment. Thus, each time another execution context first uses the same guest module deployment, guest module instance initialization (e.g., script execution) can be repeated.

[0151] For example, each execution context can have its own Java class loader. Similarly, repeated instance initialization for separate execution contexts and the same guest module deployment can repeat the execution of the same (e.g., Python) guest script 730. Thus, each execution context can have its own instance of nominally the same guest global variables.

[0152] Execution context creation can occur in the following scenarios. Although not shown, each exported guest subroutine has its own calling convention, as discussed previously. For each database session, when the call site of the calling convention of the guest module is first invoked, such as in a DML statement 771, then a new execution context can be created that exists for as long as that session. Subsequent call sites for that same calling convention or other calling conventions in that same guest module should reuse that execution context. Invoking the call site of a calling convention in a different guest module for the first time in the same session results in the creation of an additional execution context.

[0153] Typically, the execution context has the same privileges as the session of the DML statement 771. However, a DDL statement (not shown) that creates a calling convention can optionally instead specify that the execution context of the session of that DDL statement should be reserved and shared (e.g., cloned) for all sessions of all users who invoke that calling convention. Thus, user A can create a calling convention such that even when another user invokes that calling convention, the calling convention is bound to a guest subroutine that always executes with the privileges of user A, thereby temporarily elevating privileges during subroutine execution.

[0154] As discussed later in this document, a guest subroutine defined in one guest module can call a guest subroutine defined in another guest module. Typically, guest subroutines in different guest modules have different execution contexts, even for the same session. However, when a first guest subroutine calls a second subroutine, there is only one call point in DML statement 771, and it is for the first subroutine. When there is only one call point, there is only one execution context for the same session, and embodiments can reuse this execution context such that two subroutines called through the same call site (i.e., one direct call and another indirect call) should share the same execution context. Thus, the call site is the root from which the same execution context can be injected into the entire call tree of guest subroutines, regardless of guest module boundaries. The execution context is associated with the call site or call specification as follows.

[0155] In various embodiments, the guest programming language 710 can have multiple instances of the same guest module, such as one per user, per session, per transaction, per (e.g., prepared, batch) DML statement, per call specification for a DML statement, or per call specification call site. As metadata, call specifications can be shared by some or all (e.g., non - simultaneous) instances of the same guest module. For example, one embodiment may require multiple instances of the same call specification, while another embodiment may instead have only a shared singleton. Re - instantiating the same guest module for each DML transaction, statement, or call specification for a statement (i.e., regardless of how many call sites) can increase execution efficiency by balancing the re - instantiation latency and lexical isolation (i.e., correctness / security, e.g., security or compatibility).

[0156] In an embodiment, and regardless of how many call sites are in the same DML statement, each call specification instantiates its own instance of the guest module it declares. In that embodiment, no guest module lives longer than the execution of the DML statement that instantiates the guest module. Thus, each time DML statement 771 is issued, the guest script 730 runs once for each referenced guest subroutine, i.e., not once per repetition (e.g., per table row) call, nor once per call site. For example, a particular guest module may export functions foo and bar, but not splat from a different guest module. If DML statement 771 is "SELECT foo(),foo(),bar(),splat() FROM SomeTable;", then that particular guest module is instantiated twice (i.e., once for foo and once for bar). The UDF splat() can be a normal UDF implemented in SQL or can be implemented in a different guest module in the same or a different guest programming language.

[0157] A guest module can use (i.e., depend on) other guest modules, but an empty guest module as a dependency is likely to be more or less useless. It is the resources exported by a guest module (i.e., guest objects) that make that guest module useful. For example, a guest module can contain a guest script 730, which can initialize the guest module, including generating guest objects that may or may not be exported (such as to other guest modules).

[0158] As shown, DML statements 771 - 772 interact with (e.g., call) guest objects (not shown) generated by guest script 730 in the memory of the MLE (e.g., RAM). Each of those guest objects can be defined by corresponding lines of text in guest script 730, which is itself text.

[0159] Guest script 730 can depend on other guest modules, such as according to dependency 790 below. Regardless of whether the execution of guest script 730 is eager, lazy, interpreted, compiled, or based on intermediate code (e.g., bytecode), the execution of guest script 730 occurs statement by statement (e.g., line by line), which ultimately executes the imperative statement 740 in guest script 730, which is an import instruction that issues an import request 751 to dynamically link dependency 790, which symbolically identifies the guest module to be resolved (not shown). The processing of import request 751 can occur as follows.

[0160] 8.0 Example Import Process

[0161] Figure 8 is a flowchart depicting the execution of a native request 751 of guest programming language 710 to import dependency 790, which causes the DBMS 700 to provide either module 721 or 722 based on mapping 780. Refer to Figure 7 Discussion Figure 8 。

[0162] Dynamic import of dependencies according to the techniques herein can occur in three different scenarios that share the mechanisms herein. Although not shown, one scenario is caused by DDL statements for guest module creation, as follows. As shown, the other two scenarios are caused by corresponding alternative implementations for the same DML statements (such as 771 - 773). Figure 8 The discussion below addresses all three scenarios in various ways.

[0163] Step 802 receives and executes a (e.g., DDL or DML) database statement that explicitly (i.e., DDL) or implicitly (i.e., DML call site to call specification) invokes guest programming language 710.

[0164] For example, the DDL statements for guest module creation can call a guest script 730 (e.g., Python) to eagerly instantiate guest objects that can be guest subroutines, such as module 721. The guest script 730 can begin with or otherwise include dependency import instructions, which are typically imperative statements of the guest programming language 710, such as 740. However, as described below, some import instructions may already have been statically preprocessed (i.e., inlined and removed), such as before deploying the guest script 730, such as during a build (i.e., packaging) phase.

[0165] This build phase is optional for the techniques herein. However, as with general software, there can be both static linking (i.e., build phase) and dynamic linking (i.e., runtime), with some dependencies (e.g., inlining) being fully resolved and linked at build time. For example, JavaScript has static packaging tools, such as Browserify and WebPack, that can offload some of the linking to these tools, thus reducing the need for dynamic import techniques herein. While Python does not employ static inlining, tools such as Pip can shift most of the linking responsibilities to build time and away from runtime.

[0166] In any case, it may be impossible or undesirable to avoid all dynamic linking, such as for reasons elsewhere herein. Thus, at any time the guest script 730 is executed, or at any time a guest subroutine defined by the guest script 730 is later called, the imported statement(s) may execute to effect dynamic linking, which occurs as follows.

[0167] In another scenario, although less likely, the body of a guest subroutine itself can contain import statements. Thus, calling a guest subroutine (e.g., from a DML query) effects dynamic linking.

[0168] In yet another scenario that is a hybrid of the other two scenarios, the guest module is more or less frequently reinstantiated, such as for multiple execution contexts discussed later herein. For example, during execution of a DML statement 771, initialization of an (e.g., additional) execution context causes another instance of the same module deployment to be instantiated in the memory (e.g., RAM) of the DBMS 700. Thus, in the hybrid scenario, the import statements execute while the DML statement is being executed, just as in one scenario, but the import execution continues as described above for the module creation DDL statement, just as in the other scenario.

[0169] Thus, whether steps 802, 804 and 806 are caused by DDL or DML statements depends on the scenario. Similarly, whether this requires (re)execution of all guest scripts 730, or merely requires calling a guest subroutine already defined by an earlier execution of guest script 730, also depends on the scenario. Additionally, the implementation may support only one or two of the three scenarios.

[0170] Step 802 causes steps 804 and 806 as follows. Execution of guest script 730 or one of its guest subroutines can proceed by sequentially executing each guest statement, including command statement 740, which is an import instruction that, in step 804, issues an import request 751 to dynamically link and resolve dependencies 79 of a guest module (not shown) symbolically identified.

[0171] In an embodiment, the MLE of DBMS 700 has a corresponding adapter in each implementation of a guest programming language. During step 804, that adapter intercepts and specifically disposes of import request 751 as follows. Although not shown, import request 751 contains the name of dependency 790, which is required for module resolution. The MLE can use that dependency name in the next step 806 as follows.

[0172] Step 806 resolves dependency 790. The dependency name can be used as a lookup key into dependency map 780 to select a guest module that satisfies dependency 790. Dependency map 780 can be implemented by the guest virtual environment participating in dependency resolution, as discussed later herein. For example, in map 780, dependency 790 can be bound to guest module 721.

[0173] 9.0 Example Component Boundary Behavior

[0174] Figure 9 is a flowchart depicting example activities at component boundaries such as database sessions 761 - 762, DML statements 771 - 773, and guest modules 721 - 722, as follows. Refer Figure 7 Discussion Figure 9 。

[0175] Figure 9 The steps depicted involve multiple scenarios that may or may not occur together, as follows. Steps 901A - B involve the same DML statement 771 invoking two call specifications in different respective guest modules 721 - 722 of the same guest programming language 710. In other words, DML statement 771 directly depends on multiple guest modules, which implies an execution context in the following embodiments.

[0176] As explained earlier in this document, the execution context typically corresponds to a combination of a database session and a guest module. That is, calls to the same guest module during the same database session can reuse a single execution context. For example, DML statement 771 appears in database session 761. The execution of DML statement 771 spans steps 901A - B, as follows.

[0177] During step 901A, DML statement 771 calls a first UDF whose call specification resides in guest module 721. Thus, the first UDF is called within the first execution context for the combination of database session 761 and guest module 721. If the first execution context already exists, then that context is reused; if not, it is created immediately.

[0178] During step 901B, the same DML statement 771 calls a second UDF whose call specification resides in a different guest module 722. Thus, the first execution context should not be reused for calling the second UDF, even if the two guest modules 721 - 722 are defined in the same guest programming language 710. Instead, the second UDF is called within a second execution context for the combination of the same database session 761 and the different guest module 722. The second execution context is reused if it already exists, or created immediately if it does not.

[0179] As explained earlier in this document, each execution context that shares the deployment of guest module 721 with other execution contexts (e.g., other database sessions) may require its own instance of the guest module. Also as explained, each additional module instance can be initialized separately such that the guest script 730 runs again each time an additional module instance is initialized. For example, if DML statement 771 represents the first use of guest module 721 by database session 761, then guest module 721 should be instantiated for database session 761 during the execution of DML statement 771. Thus, DML statement 771 can cause guest script 730 to run, which results in steps 902A - C as follows.

[0180] As explained earlier in this document, the execution of guest script 730 can proceed by interpreting each statement within guest script 730, one at a time. For example, step 902 interpretation can be a command statement 740 that is an import directive. The interpretation of command statement 740 may not require any of steps 902B - C below, or may require one or both of them.

[0181] In step 902B, the guest programming language 710 implementation parses the script text, such as all of the text or a single text line of guest script 730. For example, step 902B can generate a Truffle AST or append to an existing Truffle AST.

[0182] Depending on the guest programming language 710, the command statement 740 can initially be bytecode or can be dynamically compiled into bytecode by step 902B. In either case, step 902C interprets intermediate code such as bytecode. Thus, although not shown, step 902B may or may not cause step 902C.

[0183] The DML statement 771 can call a UDF, which calls a guest subroutine through a call specification, such as with either of steps 901A - B. However, that guest subroutine itself can call other guest subroutines in other guest modules of the same guest programming language 710, as shown in steps 903A - B. For example, the DML statement 771 can directly call (i.e., shown as step 903A) a guest subroutine through a UDF and a call specification in guest module 721, which in turn calls a guest subroutine in a different guest module 722 through its own guest logic, as shown in step 903B.

[0184] Thus, like steps 901A - B that cross the boundary between two guest modules, steps 903A - B also cross the boundary between modules. However, steps 903A - B share the same execution context. However, steps 901A - B do not share the same execution context. Thus, whether the boundary between guest modules causes a switch between two execution contexts depends on the scenario.

[0185] An empty guest module may be more or less useless. Dependencies or imports for a guest module are only needed because the guest module contains the required resources (i.e., guest objects) such as guest subroutines. However, the required guest objects do not have to be subroutines, but can instead be data objects such as arrays. For example, multiple mutually - dependent guest modules 721 - 722 of the same guest programming language 710 can share the same array constructed by guest module 721. For example, in step 904, the logic in guest module 722 can import guest module 721 and then reference that array.

[0186] A guest subroutine or guest script itself can issue a DML statement, as shown in step 905. For example, the DML statement 771 can be SQL that calls a UDF implemented by a guest subroutine that issues an additional SQL query by its client logic. Thus, the MLE of the DBMS 700 has a fully bi - directional interface between SQL and the guest programming language 710, which may require making the database session 761 available to that guest subroutine as the current or default database session, which can be achieved as follows.

[0187] In an embodiment, since each execution context can have its own independent instance of global variables, as explained earlier in this document, that global variable can store the database session 761 as the current session. In another embodiment, the current database session is exported, or a factory subroutine that returns the current database session is exported, and either of those is exported from such a module that operates like a guest module but is native to the DBMS 700 and does not have a guest programming language, or the guest programming language is a DML such as PL / SQL or T / SQL. The guest module 721 may need to import that native module to access the current database session.

[0188] 10.0 Example Dependency Resolution Process

[0189] Figure 10 is a flowchart depicting example activities for satisfying dependencies 790 in an embodiment. Additional dependency satisfaction techniques will be presented later. Refer to Figure 7 Discussion Figure 10 。

[0190] Step 1002 loads and caches the guest module 722 into the memory buffer 705 of the DBMS 700. For example, the DML statement 771 in the database session 761 causes the import request 751 to access the dependency 790, as explained earlier in this document. Also as explained, the DBMS 700 uses the mapping 780 to decide which actual guest module should be used to satisfy the dependency 790. The implementation of the mapping 780 will be presented below. For example, the guest module 722 can be selected to satisfy the dependency 790.

[0191] Step 1004 can execute the DML statement 773 in a different database session 762, which can call the call specification of the UDF to call a guest subroutine, which can execute the import request 752 to access the same dependency 790, as shown in step 1006. As explained elsewhere in this document, which guest module will be selected for the dependency 790 in step 1008 depends on the mapping 780 that can be based on the current database session and / or the current execution context. Thus, the dependency 790 that was resolved to the guest module 721 in step 702 can instead be resolved to a different guest module 722 in step 708. Additional mechanisms for such resource alternation will be presented later in this document, such as guest virtual environments.

[0192] 11.0 Multilingual Integration

[0193] Figure 11FIG. 0 is a block diagram depicting an example software container 1100 in an embodiment. The software container 1100 has a multilingual engine (MLE) that facilitates cooperation between different guest programming languages 1112-1113, as described below. The software container 1100 may be an implementation of the DBMS 110.

[0194] Depending on the embodiment, the software container 1100 may be any middleware capable of loading and executing custom logic, such as platform as a service (PaaS) or infrastructure as a service (IaaS). For example, the software container 1100 may be an application server such as a web server, a control inversion (IoC) container such as Spring, a virtual machine (VM) such as a hypervisor or a Java virtual machine (JVM), a programming language interpreter for scripts or bytecode, an application container such as Docker or Kubernetes, or a DBMS such as an RDBMS.

[0195] As discussed previously herein, the MLE of the software container 1100 has innovative integration mechanisms, including: a) hosting of multiple guest programming languages 1112-1113, b) loading and operation of guest modules (not shown), c) resolution of symbolic dependencies (not shown) between guest modules, and d) generation and exposure of call specifications such as 1120. Also as explained previously herein, the MLE may innovatively intrude (i.e., intercept) and enhance the operation of guest programming languages 1112-1113, such as importing and exporting guest objects as shared resources.

[0196] The MLE may be implemented such that, through some language-specific adapters, most or all of the core functions of the MLE can be used in a language-neutral manner. In an embodiment, the MLE transparently facilitates cooperation between multiple guest languages 1112-1113 based on the cooperation of guest modules as functional units through the following mediation interface. For example, a guest module of the guest programming language 1112 may interact with a guest module of the guest programming language 1113, and neither guest module knows which language the other module uses. Thus, the software container 1100 achieves more or less complete interface compatibility of guest languages that can cooperate, for example, to assist in executing statements expressed in the native programming language 1111.

[0197] The native programming language 1111 is fully integrated into the software container 1100. For example, when the software container 1100 is a DBMS, the native programming language 1111 can be a query language, such as DML, such as SQL. As another example, the software container 1100 can be implemented in the native programming language 1111. For example, when the software container 1100 is Spring IoC implemented in Java, the native programming language 1111 can be Java. In an embodiment, the native programming language 1111 is a domain-specific language (DSL), which may or may not be proprietary to the software container 1100.

[0198] As explained earlier herein, for a DBMS for example, the software container 1100 generates a call specification, such as 1120, for a subroutine of the guest programming languages 1112-1113. For example, the call specification 1120 can export a subroutine of the guest programming language 1112 as a UDF in the native programming language 1111. The UDF call specification 1120 has one or more arguments, such as 1141, and / or a return value of a corresponding data type native to the native programming language 1111. The call specification 1120 also includes a data binding 1131 that converts the arguments from the data type of the native programming language 1111 to the data type of the guest programming language 1112, such as for the guest parameter 1142, and vice versa for the return value and / or OUT parameter. Thus, the languages 1111-1112 are more or less completely isolated from each other's type systems, such that neither language 1111-1112 is exposed to the data types of the other language.

[0199] The binding 1131 is not a binding between two guest programming languages and can instead be implemented as follows. As explained, the binding 1131 can convert the data types of the languages 1111-1112 bidirectionally as a first binding. Similarly, the native programming language 1111 can also have a second binding (not shown) that converts the data types of the languages 1111 and 1113 bidirectionally.

[0200] In an embodiment, the binding 1132 between the guest programming languages 1112-1113 can be a coupling of both the first and second bindings (not shown). Thus, as an intermediate representation, the data type of either of the guest programming languages 1112-1113 is initially converted to the data type of the native programming language 1111 and then to the other of the guest programming languages 1112-1113. For example, the binding 1132 can convert a Python string to an SQL string and then to a JavaScript string so that a Python module can pass a value to a JavaScript module.

[0201] This approach is extensible because each guest programming language only needs to provide a two-way data binding (i.e., to the native programming language 1111). In another embodiment, the binding 1132 does not use the native programming language 1111 data types as an intermediate representation, but instead the binding 1132 directly converts between the data types of the guest programming languages 1112 - 1113. This approach can have higher runtime efficiency.

[0202] Regardless of how the data binding 1132 is implemented, the components of the software container 1100 can be arranged as shown to enable the multi-language execution of queries. Integration techniques such as call specifications, data binding, and module dependency resolution facilitate the configuration of mutually dependent guest modules in a way that transparently enables control and / or data flow between modules of different guest programming languages. For example, a query to the native programming language 1111 can call a subroutine in the guest programming language 1112, which accesses resources such as an object 1150 in the guest programming language 1113.

[0203] Thus, the execution of queries can cross guest language boundaries to participate in the guest programming languages 1112 - 1113 in a cooperative manner. From this interoperability, there can be various emergent benefits as follows.

[0204] For example, different responsibilities of the same query can be assigned according to the natural advantages of the guest programming languages 1112 - 1113. For example, Uniform Resource Locator (URL) handling can be delegated to the guest programming language 1112, which in turn delegates regular expressions to the guest programming language 1113.

[0205] For example, application developers will not be limited to any one guest programming language and can thus have a large number of third-party (e.g., open source) resources in many guest programming languages to be deployed as guest modules at any time. This may shift the buy-versus-build trade-off away from in-house feature development, thus accelerating development and / or reducing development costs. In turn, this can encourage more ambitious (i.e., feature-rich) database applications and / or promote integrated service topologies with fewer (e.g., middleware) layers such as application servers, which can reduce operational / management costs and skills.

[0206] 12.0 Example Guest Object Access Process

[0207] Figure 12 is a flowchart depicting example activities for accessing a guest object 1150 of the guest programming language 1113 from different guest programming languages 1113 in an embodiment. Refer to Figure 11 Discussion Figure 12 .

[0208] Step 1202 is preparatory and, as discussed earlier herein, creates the guest object 1150 in the guest programming language 1113, including activities such as guest module instantiation, guest script execution, guest object export, and various database dictionary insertions. Step 1204 calls the different guest programming language 1112 from the native programming language 1111 statements, as discussed earlier herein. For example, the call specification 1120 can mediate between the native programming language 1111 and the guest programming language 1112, including the operation of the binding 1131 for argument data type conversion as described above. Thus, step 1204 transfers control from the native programming language 1111 to the guest programming language 1112, which may or may not require the generation and / or switching of the execution context, as discussed above.

[0209] Step 1206 executes a request to access the guest object 1150 in the guest programming language 1113 from the different guest programming language 1112. Again, as discussed, this may or may not require the generation and / or switching of the execution context. Step 1206 crosses the language boundary in a manner more or less similar to step 1204, which also crosses the language barrier. As discussed above herein, as with each of steps 1204 and 1206, stepping into the guest programming language requires some or all of the following: a) execution context generation and / or switching, b) guest module resolution and / or instantiation, with or without guest script execution, c) argument data type conversion and / or validation, such as through bindings 1131 or 1132, d) overloaded signature resolution, and e) the actual transfer of control to the guest programming language, such as the call and interpretation of a guest subroutine or other execution.

[0210] As explained above, a guest script or guest subroutine can issue an instruction to import a dependency. That issuing script or subroutine does not need to know which guest module of the same or other guest programming language implementation can satisfy that dependency. For example and depending on the dependency mapping discussed above and below herein, in the various scenarios presented herein, the same dependency can be satisfied by different guest modules of the same or different guest programming languages. For example, due to an expected replacement or due to an unexpected name conflict, the same dependency can be resolved to a Python guest module for one client and to a JavaScript guest module for another client.

[0211] The implementation of a multilingual engine can use some decoupling mechanisms, including reusable data structures and / or generated glue logic, to achieve this multilingual module pluggability. Lookup tables and hash maps provide more or less passive translation based on indirection. For example, as discussed elsewhere herein, there can be passive, eager, or lazy adapters that translate the native modular frameworks of guest programming languages into the guest module mechanisms and techniques taught herein. For example, as discussed herein, the native data types and other structures native to software containers 1100 and / or native programming languages 1111, such as aspects of SQL, may or may not be used as the canonical representation into which all guest language data types are translated or from which they are translated. In an embodiment, namespaces such as guest virtual environments facilitate module coupling as follows.

[0212] 13.0 Guest Virtual Environments

[0213] Figure 13 is a block diagram depicting an example computer 1300 in an embodiment. The guest virtual environments 1311-1312 of computer 1300 provide alternative bindings of the same-named dependencies to different guest modules as follows. Computer 1300 may include an implementation of DBMS 110.

[0214] As explained above, guest modules (such as 1341-1342) may depend on another guest module to satisfy a dependency. Also as explained above, issues such as isolation and codebase version control limit the sharing of guest modules. For example, multiple instances of the same module deployment may be required, or different codebases (e.g., release versions) of similar modules may be required, and / or resource name conflicts may need to be avoided. Thus, computer 1300 has guest virtual environments 1311-1312 that provide isolation, such as for multi-tenancy.

[0215] Guest virtual environments 1311-1312 are namespaces that provide a mapping (i.e., binding) (not shown) between some symbolic dependencies (i.e., names as discussed herein) of guest modules 1341-1342 and other guest modules (not shown), and other guest modules serve as the implementation (i.e., definition as discussed herein) of those dependencies. In this sense, each of the guest virtual environments 1311-1312 operates as a namespace, and each of the guest modules 1341-1342 gains visibility into other required guest modules through the namespace. Thus, a database application can more or less consist of cooperating guest modules. In an embodiment, each of the guest virtual environments 1311-1312 is implemented as an associative data structure, such as a dictionary or hash table, that stores the bindings of guest modules for lookup, as described below.

[0216] In an embodiment, computer 1300 includes an RDBMS or other DBMS. Other embodiments do not include a DBMS. In the illustrated embodiment, computer 1300 receives and executes DDL statements 1321 - 1323, such as for a DBMS, for creating or otherwise managing guest virtual environment 1312. Other embodiments may receive and execute commands, although not DDL and / or not for a DBMS, that can also create and manage guest virtual environment 1312. DDL statements 1321 - 1323 are examples of implementation choices for computer 1300. Thus, the following discussion of the techniques of DDL statements 1321 - 1323 can be readily applied to implementations that do not require a DBMS or DDL. In an embodiment, computer 1300 includes software containers that are not a DBMS, such as presented earlier herein. In an embodiment, computer 1300 requires neither a DBMS nor any of the other software containers described earlier herein.

[0217] DDL statement 1323 creates a new guest virtual environment 1312 in computer 1300. DDL statement 1323 can specify the database schema in which guest virtual environment 1312 is defined, which can default to the current schema of the database session that issues DDL statement 1323. DDL statement 1323 can optionally specify an existing guest virtual environment to be used as a prototype from which a clone can be generated. For example, DDL statement 1323 can specify that new guest virtual environment 1312 should be cloned from existing guest virtual environment 1311. The clone replicates all dependency bindings, and without a clone, new guest virtual environment 1312 initially has no dependency bindings at all.

[0218] DDL statement 1321 adds new dependency bindings to an existing guest virtual environment 1311. For example, the details of DDL statement 1321, shown as import 1360, can specify the name of the dependency and the name of the guest module that is bound to that dependency. For example, a guest module 1341 in guest programming language 1350 can import a dependency by name, such as with a require() statement (not shown). A multi - language engine (MLE) (not shown) in computer 1300 can intercept and specifically process import instructions (i.e., requests), such as require(). For example, calling require() can specify a dependency name, and the MLE can use this as a lookup key to select a binding in guest virtual environment 1311. The selected binding can identify another guest module that the requesting guest module 1341 should use to obtain resources related to that require() call.

[0219] To resolve dependencies, each guest module instance has a corresponding guest virtual environment. For example, a DDL statement (not shown) that creates a guest module can specify an existing guest virtual environment. If no guest virtual environment is specified, then computer 1300 provides a default guest virtual environment for the guest module.

[0220] Multiple guest modules 1341-1342 can share the same guest virtual environment 1311. This sharing occurs regardless of whether the guest modules 1341-1342: a) have different code bases, b) are defined in different guest programming languages, c) are imported by other guest modules defined in different guest programming languages, and / or d) are loaded for different user accounts and / or database sessions.

[0221] Guest module 1341 can initially be assigned to guest virtual environment 1311 and then reassigned to guest virtual environment 1312, such as via a DDL statement (not shown). In an embodiment, this reassignment causes guest module 1341 to be (e.g., lazily) reloaded based on guest virtual environment 1312. For example, the Python script implementing guest module 1341 can be rerun.

[0222] DDL statement 1322 has details shown as reassign 1370, which replaces an existing dependency binding in guest virtual environment 1311 with a new dependency binding. Thus, dependencies can be remapped to different guest modules, such as a new release version of a guest module. In an embodiment, DDL statement 1322 is not retroactive, such that guest modules that have used guest virtual environment 1311 are not affected by changes to guest virtual environment 1311. For example, guest modules 1341-1342 can use concurrent different versions of guest virtual environment 1311, respectively.

[0223] Depending on the embodiment, any one of DDL statements 1321-1323 can specify: a version number of a guest programming language, configuration settings of a guest programming language, and / or a resource loading path, such as discussed later herein. Each guest virtual environment is defined in a database schema, which can contain multiple guest virtual environments. A data control language (DCL) statement 1330 can manage usage permissions for guest virtual environment 1311.

[0224] 14.0 Example Guest Virtual Environment Process

[0225] Figure 14 is a flowchart depicting example activities for generating, modifying, and using guest virtual environment 1311 that symbolically binds guest dependencies to guest modules in an embodiment. Refer to Figure 13 Discussion Figure 14 .

[0226] Step 1402 generates a guest virtual environment 1311, which is initially empty (i.e., not bound). For example, the DDL statement 1323 can be "CREATE MLE ENV scott.'myenv' ;" This creates the guest virtual environment 1311 and names it myenv in the database schema scott.

[0227] The initially empty guest virtual environment 1311 may or may not be ready for use as its purpose is to map dependencies to corresponding guest modules. In the guest virtual environment 1311, step 1404 adds bindings for dependencies. For example, the DDL statement 1321 can be "ALTER MLE ENV scott.'myenv' ADD IMPORT hello MODULE scott.'hello' ;" This specifies binding the dependency named hello to the import 1360 of the guest module 1341 in the guest virtual environment 1311.

[0228] The guest module 1341 was or (e.g., is or will be) instantiated in the guest programming language 1350. However, the guest module 1342 is instantiated in the same or a different programming language. In any case, the execution of a guest script or guest subroutine in the guest module 1342 can issue a request to access the dependency named hello, such as with an import instruction as shown in step 1406. Step 1406 uses the guest virtual environment 1311 to resolve the dependency named hello by selecting the guest module 1341. For example, the guest module 1342 can use the guest virtual environment 1311 based on the metadata of the guest module 1342 or based on the current execution context, current database session, or current database schema.

[0229] During step 1406, the guest virtual environment 1311 is used to resolve the dependency hello on which the guest module 1342 depends on the guest module 1341, which may or may not also require activities such as loading, instantiating, and / or reusing the guest module 1341.

[0230] In conjunction with MLE as described herein, the guest virtual environment 1311 can: a) contain bindings to guest modules implemented in many guest programming languages, b) be used at runtime (e.g., query) for resolution by guest modules defined in many guest programming languages, and c) be used to facilitate crossing the boundary between any two guest programming languages. Thus, the guest virtual environment 1311 is language-neutral.

[0231] 15.0 Guest Virtual Environment Sharing

[0232] Figure 15is a flowchart depicting an example activity for sharing a guest virtual environment 1311 among multiple database users and multiple guest programming languages, such as in a multi-tenant environment, such as with multiple database applications that are cooperative or isolated (i.e., non-cooperative), such as in a private cloud of an enterprise in an embodiment. Refer to Figure 13 Discussion Figure 15 .

[0233] Figure 15 Presents various scenarios that may or may not be independent of each other. Step 1502 executes a DCL statement 1330 to grant or revoke certain access by some user accounts or roles in computer 1300 to an existing guest virtual environment 1311. For example, security and safety may encourage the DCL statement 1330 to be used only to grant read-only access to the guest virtual environment 1311 to most users.

[0234] However, in steps 1504A - B, user accounts lacking permission to modify the guest virtual environment 1311 can approximate such a modification as follows. Step 1504A executes a DDL statement 1323 to generate a guest virtual environment 1312 as a modifiable clone of the guest virtual environment 1311. Step 1504B executes a DDL statement 1322 that includes a reassignment 2370 to add or replace bindings between named dependencies and available guest modules 1342 in the guest virtual environment 1312.

[0235] Accordingly, the cloned guest virtual environment 1312 can be customized, such as by replacing the binding between a named dependency and a guest module 1341 with a new binding between the named dependency and a different guest module 1342. Thus, through cloning, module replacement is possible, such as when one database application requires a patched (e.g., third-party) library and another database application in the same DBMS of computer 1300 must continue to use an older but more stable version of that library.

[0236] The data structure and lexical scope of the dependency bindings can depend on the embodiment. For example, step 1506 can bind a dependency name to a guest module within one or more data structures, such as: a guest virtual environment, a database schema, and / or a database dictionary. The MLE of computer 1300 can be designed to resolve dependencies based on such (one or more) relevant data structures.

[0237] Those data structures, such as guest virtual environments, facilitate sharing and reuse. For example, requests to import the same dependency name, such as during step 1508A, can be resolved to the same guest module or a similar instance of the same deployment of a guest module during step 1508B. This sharing occurs even if those import requests are from different user accounts, different database sessions, or even from different guest programming languages. This is because binding structures such as guest virtual environments can be shared or cloned, or different guest virtual environments can otherwise be configured to include some identical bindings.

[0238] 16.0 Virtual File System

[0239] Figure 16 is a block diagram depicting an example software container 1600 in an embodiment. The software container 1600 transparently retrieves resources 1681 - 1682 from a virtual file system such as 1650 to generalize alternative storage mechanisms 1671 - 1674, as described below. The software container 1600 can be an implementation of the DBMS 110. Various embodiments of software containers have been discussed previously herein, including some embodiments that do not require a DBMS or DML. Thus, the techniques using a DBMS or DML with the software container 1600 are presented herein as part of an exemplary implementation option that may not exist in other embodiments. Other embodiments may use these described techniques without requiring either a DBMS or DML.

[0240] The software container 1600 has a storage of flexible persistent data resources, such as the deployment of guest modules (i.e., codebases). The alternative storage mechanisms 1672 - 1674 provide features that a physical file system such as 1671 typically does not have. Those features can support the use of codebases in a special way that is transparent to application developers and clients, such as client sessions 1611 - 1612, as described below. Similarly, the software container 1600 can enforce permissions orthogonal to the physical file system 1671. For example, the software container 1600 can execute as an operating system (OS) superuser that can access all files of the physical file system 1671 but deny access to specific database clients, such as according to a previous data control language (DCL) grant.

[0241] For example, a guest module (not shown) may be implemented by one or more persistent objects of code or data such as runnable scripts, class files, pictures, and / or spreadsheets (such as Resources 1681 - 1682). Such persistent objects may be stored as loose (i.e., separate) files, aggregated in an overall archive file (i.e., a library), or stored in other ways for mass storage, as described below. The persistent objects may be juxtaposed with metadata objects (e.g., lists or descriptors) that the virtual file system 1650 may analyze to facilitate resource loading.

[0242] The kind and nature of the client sessions 1611 - 1612 depend on the embodiment. The client sessions 1611 - 1612 encapsulate sequences used by separate (e.g., forcibly isolated) clients, which may or may not overlap in time. In an embodiment, the software container 1600 is an RDBMS or other DBMS, and the client sessions 1611 - 1612 are database sessions. In an embodiment, each of the client sessions 1611 - 1612 is remote and has its own separate network or inter - process connection. For example, the client sessions 1611 - 1612 may more or less correspond to Hypertext Transfer Protocol (HTTP) sessions and / or the session layer (aka layer 5) of the Open Systems Interconnection (OSI) network stack. In the illustrated embodiment, the software container 1600 has the client sessions 1611 - 1612. In other embodiments, the software container does not require client sessions. For example, the software container may receive commands from a queue or a controller, and these commands may be mixed, ambiguous, or lack session boundaries. For example, multiple clients may submit commands to the same queue that the software container 1600 depends on, regardless of the command origin.

[0243] The software container 1600 provides a highly dynamic import (e.g., loading) of resources. Resources are typically imported during the initialization of a guest module instance (not shown), such as when the client session 1611 first calls any call specification (not shown) of the module, which is somewhat dynamic. However, resource import (e.g., the require() script statement) may occur at any time during the execution of the guest logic of the guest programming language 1630. For example, a require() call may be conditional (e.g., within an if statement) and issued from within a highly dynamic guest subroutine (not shown). In any case, DDL or DML statements (such as 1621 - 1622) may cause the loading of guest modules and / or guest objects. For example, the DML statements 1621 - 1622 may issue corresponding native requests 1641 - 1642 to import the same dependencies 1660, such as with a require() call.

[0244] An embodiment of the software container 1600 that does not require a DBMS can accept commands that are neither DML nor DDL. Thus, the DML statements 1621-1622 are examples of implementation choices. In other embodiments, the techniques herein can enable similar use of the virtual file system 1650 without a DBMS, DML, or DDL.

[0245] The file system implementation backends 1671-1674 are mutually exclusive alternatives, shown by the dashed arrows. The software container 1600 can have many virtual file systems, such as 1650, but each virtual file system has only one corresponding implementation backend. As shown by the solid arrow, the virtual file system 1650 uses the archive file 1672 as its backing store.

[0246] For example, the virtual file system 1650 can resolve the dependency 1660 by selecting a resource (not shown) within the archive file 1672 that can contain many resources. For example, the archive file 1672 can be a (e.g., compressed) zip file, a tape archive (tar) file, or a Java archive (jar) file. In an embodiment, the virtual file system 1650 extracts that resource from the archive file 1672, such as by decompressing and according to a list (not shown) within the archive file 1672 that lists the original files contained within the archive file 1672.

[0247] In an embodiment, the virtual file system 1650 can directly use the extracted resource. In another embodiment, the virtual file system 1650 can decompose (i.e., unpack) the files within the archive file 1672 into an actual file system, such as 1671. For example, virtual file systems can be cascaded such that one can delegate to another for features such as unpacking and / or caching. For example, virtual file systems can be aggregated (e.g., daisy chained) into a collection of load paths (such as a class path or a module path).

[0248] As discussed earlier herein, the parser, compiler, and / or interpreter of the guest programming language 1630, which is part of the multi-lingual engine (MLE) of the software container 1600, can intercept and specially process the native requests 1641-1642. For example, the native request 1641 can specify a qualified or unqualified name of the dependency 1660, and the MLE or the guest compiler can analyze that name to identify the symbolic name of the dependency 1660. As discussed earlier herein, the guest virtual environment (not shown) can map the symbolic dependency to an actual guest module instance. For example, the dependency 1660 can be mapped to a guest module whose codebase is the archive file 1672. Thus, the MLE, the guest virtual environment, and the virtual file system 1650 can cooperate to dynamically satisfy the dependency 1660.

[0249] In an embodiment, the virtual file system may operate as a resource cache. For example, the virtual file system may be implemented by a memory buffer 1673, which may cache some or all of a guest module, including resources 1682. For example, the virtual file system 1650 may decompose an archive file 1672 into the memory buffer 1673. Resources 1682 may be static resources (such as pictures), or may be computed (i.e., dynamically generated) guest objects (such as JavaScript Object Notation (JSON) data structures generated by an initialization script of a guest module).

[0250] In an embodiment, an entire guest module or individual resources within that module may each be stored as large objects (i.e., BLOBs or CLOBs) in a column 1690 of a database table 1674. Thus, module resources may be managed according to database semantics rather than native file system semantics. The virtual file system may automatically issue (e.g., generate) the DML required to access database column 1690.

[0251] 17.0 Example Virtual File System Processes

[0252] Figure 17 is a flowchart depicting example activities in which a software container 1600 retrieves resources such as 1681 - 1682 from a virtualized storage device such as a virtual file system 1650. Refer to Figure 16 Discussed Figure 17 .

[0253] Step 1702 invokes the guest programming language. For example, a DML statement 1621 may be executed. In step 17, that guest programming language executes a request 1641, such as an import instruction, to access a dependency 1660, as explained earlier herein.

[0254] Satisfaction of the dependency 1660 may occur in two phases. In the first phase, the MLE of the software container 1600 resolves the dependency 1660 for a particular guest module (not shown), such as according to bindings such as those included in a guest virtual environment (not shown). Depending on the scenario, the guest module may already be loaded, or may not yet be loaded.

[0255] In the second phase, step 1706 retrieves the resource 1681 that satisfies the dependency 1660. If the resolved guest module has not been loaded, then step 1706 occurs, or it may sometimes occur even if that guest module has already been loaded, as explained later herein.

[0256] Step 1706 detects where and how the resource 1681 is stored. Since Figure 17This process typically occurs during the creation / instantiation of the guest module, so the resource 1681 can be one or more guest scripts in the code library of the guest module, which can be one or more (e.g., text or class) files in the actual file system 1671. Alternatively, the dependency 1660 can be satisfied by resources in any data repository 1672 - 1674. Thus, step 1706 detects in which data repository the resource to be saved is located.

[0257] As explained earlier in this document, the code library of the guest module is typically identified by any DDL statements that create the guest module. Thus, the software container 1600 can maintain metadata that describes the guest module, including details such as the location and type of the data repository that contains the code library of the guest module. Whenever that guest module is (re)instantiated, the software container 1600 can consult that metadata to detect where and how that code library is stored.

[0258] The deployment of the guest module can be shared, such as when two database sessions each need their own instance of that guest module. For example, two database sessions can each execute the same guest script to initialize each instance of the guest module. The virtual file system 1650 is a data storage adapter that the two sessions can share to gain access to the same resources, such as all or part of the code library of the guest module. As an adapter, the virtual file system 1650 hides from the rest of the MLE of the software container 1600 the actual data storage type used for the guest module. Thus, the virtual file system 1650 provides a unified appearance or interface through which resources can be retrieved without exposing the retrieval mechanism.

[0259] The software container 1600 can include the virtual file system 1650 within the metadata of the guest module. Thus, step 1706 can locate and retrieve the resources for the dependencies to be resolved by accessing the virtual file system 1650 associated with any guest module to which the dependencies are resolved. For example, a DML query may require several dependencies, and the MLE of the software container 1600 can resolve those dependencies to specific guest modules and transparently load those guest modules in a unified and storage - independent manner, even though each of those guest modules may actually reside in very different data repositories.

[0260] 18.0 Example Implementations

[0261] The following are example implementations selected based on a specific implementation. For example, the DBMS is a relational DBMS (RDBMS). Also, DDL, DCL, and DML are provided by SQL.

[0262] Included in this example implementation are database statements for configuring and operating the novel multi - language database components presented in this example implementation and elsewhere herein. In this example implementation, the guest component may also be referred to as the MLE component. For example, the MLE module is the guest module. This example implementation demonstrates support for the following languages: SQL, Java, JavaScript, and Python. The MLE used in this example implementation also supports adding more guest programming languages.

[0263] This example implementation highlights the integration between the MLE and the corresponding modular (e.g., package) frameworks that are native and / or best - in - class for various guest programming languages. For example, guest modules can be arranged by design into a hierarchy of subdirectories, and package naming can reflect that hierarchy. For example, guest modules are bound and resolved by name, and such names can reflect that hierarchy. However, other embodiments of the MLE do not require imposing hierarchy semantics on names and / or subdirectories.

[0264] In embodiments, the virtual file system, guest virtual environment, and / or one or more other MLE components that support guest modules can directly support hierarchical behavior / aspects such as name tagging, sub - folder enumeration, parent folder, case - sensitivity, and / or manifest. Also as described above herein and shown below, other features of guest - native modularity that the MLE can integrate include interdependence, visibility, deferred loading, decompression, version, and / or search order.

[0265] 18.1 Creating an MLE Language

[0266] Before an MLE function that executes in that language can be created and executed, the MLE language should be added to the RDBMS. A new MLE language can be added to the database using the CREATE MLE LANGUAGE DDL:

[0267] CREATE MLE LANGUAGE MYLANGUAGE;

[0268] This creates a schema object whose identifier matches the specified language name (in this case, MYLANGUAGE). The DDL statement will register the existing MLE language implementation provided by the MLE plug - in library using the RDBMS dictionary. This DDL does not rely solely on predefined language registration but enables the user to register his own MLE language implementation in the database.

[0269] 18.2 Runtime State Isolation

[0270] When MLE language code (such as a dynamic MLE fragment or a function exported by an MLE module) is executed in a session, the runtime state associated with the execution is encapsulated in an execution context. The runtime state includes global variables and the state of the language environment. An execution context is an independent and isolated runtime environment for one or more MLE languages. All code sharing an execution context has full access to all of its runtime state (e.g., any global variables defined previously). In contrast, code executed in one execution context cannot view or modify the runtime state in another execution context.

[0271] MLE uses execution contexts for function and procedure calls from SQL and PL / SQL. Here, the execution context separates the runtime states of different users and different MLE modules.

[0272] 18.3 Code Management with MLE Modules

[0273] MLE language code can be permanently stored as an MLE module. An MLE module is a schema object that contains code written in a single MLE language. An MLE module corresponds to the concept of a "library" or "module" in the corresponding MLE language. For example, a JavaScript MLE module is a JavaScript UMD module.

[0274] The code in an MLE module can be used in two different ways:

[0275] · Functions exported by an MLE module can be published by creating a call specification. An MLE call specification can be called from SQL and PL / SQL just like PL / SQL functions and procedures.

[0276] · An MLE module can be imported by other MLE code written in the same language. For example, JavaScript code executed in MLE can import a JavaScript MLE module using require().

[0277] · Once MLE supports more languages than JavaScript, an MLE module written in one language can be imported by code written in another language.

[0278] MLE provides DDL commands to manage MLE modules in the database (e.g., create, alter, delete).

[0279] 18.4 Creation of MLE Modules

[0280] Use the CREATE MLE MODULE DDL statement to create an MLE module in the database, specifying the name and source code of the MLE module:

[0281] CREATE MLE MODULE scott."jsmodule"

[0282] LANGUAGE JAVASCRIPT

[0283] AS module.exports.func = function() {...}

[0284] The DDL statement for creating an MLE module is discussed further elsewhere in this article.

[0285] Each MLE module can only contain code written in a single MLE language. This language is specified in the DDL statement when creating the module (for example, the above DDL statement creates a JavaScript module). The specified language should be one of the MLE languages added to the database via CREATE MLE LANGUAGE.

[0286] The name of the created module can be fully qualified, as in the above example, that is, the schema (scott) and the name of the module created in the schema ("jsmodule"). If the schema name is omitted, then the module is created in the current user's schema.

[0287] The name of an MLE module should be unique within the schema. Like other schema object identifiers, if the module name is enclosed in double quotes, then it is case-sensitive. If the enclosing double quotes are omitted, then the name is implicitly converted to uppercase.

[0288] The source code of an MLE module can be specified inline using the AS clause, or it can be obtained from a BFILE, BLOB, or CLOB.

[0289] An MLE module can be updated by replacement. This is done by specifying OR REPLACE in the module creation DDL, and the advantage is that previously granted object privileges remain valid after replacement.

[0290] CREATE OR REPLACE MLE MODULE scott."jsmodule"

[0291] LANGUAGE JAVASCRIPT

[0292] AS module.exports.bafsfunc = new function() {...}

[0293] The user should have the CREATE MLE MODULE privilege to create an MLE module in their own schema, or the CREATE ANY MLE MODULE privilege to create an MLE module in any schema.

[0294] 18.5 Structure of MLE Modules

[0295] The structure of an MLE module depends on the language. For each MLE language, the MLE module corresponds to the code "unit" of that language (e.g., UMD modules for JavaScript, modules or packages for Python). An MLE module can also optionally bundle some or all of the dependencies of the code unit it encapsulates.

[0296] How JavaScript, Python, and Java MLE modules are structured is described below.

[0297] 18.6 JAVASCRIPT MLE Modules

[0298] JavaScript MLE modules are UMD modules, the standard format for writing modules in JavaScript. UMD modules export functions (or more generally values) by assigning them to fields of the module.exports object. The require() function of Node.js can be used to import UMD modules. The require() function evaluates the content of the module and returns the module.exports object, through which the importer can access the functions exported by the imported module.

[0299] For example, the UMD module in the following logic exports a single function squareAndAdd().

[0300] The module text also defines a function square() for implementing squareAndAdd(). However, this function is not exported, so it cannot be directly called from the code that imports this module.

[0301]

[0302]

[0303] The UMD module itself can use require() to import other UMD modules and can require specific versions (or version ranges) of dependencies to work correctly. Information about all dependencies of a JavaScript module, including names and versions, is typically contained in the package.json file. These dependencies can be installed using npm install, which reads the package.json file and fetches the dependencies from the package registry.

[0304] Tools such as browserify and webpack can be used to bundle a UMD module and all its dependencies into a single UMD module. The bundled module exports the same set of functions as the original module, but in addition, it inlines the code from all its dependencies. The require() statements for the bundled module are removed, and all calls to its functions are replaced with calls to its inlined code.

[0305] JavaScript MLE modules are UMD modules that can bundle some or all of their dependencies. Unbundled dependencies for a JavaScript MLE module (i.e., any module loaded via a require() call in the text of the deployed module) are satisfied via in-language module imports.

[0306] The SIGNATURE clause of a call specification can refer to one of the exported functions of a JavaScript MLE module. When such a call specification is invoked, the MLE loads the module in a manner similar to the require() function: it evaluates the contents of the module and looks up the named function in the module.exports object and calls it.

[0307] 18.7 Python MLE Modules

[0308] Python MLE modules contain Python modules or packages. Modules and packages are the standard way to encapsulate code in Python and can be imported by other Python code via the import statement.

[0309] A Python module is a collection of statements that is typically contained in a single source file. For example, the following logic shows a Python module that defines two functions:

[0310]

[0311]

[0312] Python modules do not explicitly export functions and values. Any identifier defined in the text of a Python module is accessible to the code that imports it. However, by convention, identifier names that begin with an underscore ('_') are considered private. All other definitions in the module text constitute the public API of the module. When a module is imported, the import statement returns a module object that encapsulates all the values (including functions) declared in the module text.

[0313] Python packages are a way to further organize large codebases. A package can be thought of as a directory in the file system that contains Python modules and can contain other packages. For example, the contents of the above module could be split into two separate modules (e.g., exports.py and helpers.py) and placed in a directory (e.g., pypackage) as follows.

[0314] This logic could be in helpers.py:

[0315] def square(val):

[0316] return val*val

[0317] This logic could be in exports.py:

[0318] from.import helpers

[0319] def squareAndAdd(val1,val2):

[0320] return helpers.square(val1)+helpers.square(val2) Components of the package can be imported individually (e.g., import pypackage.exports), or the package itself can be imported (import pypackage). In the latter case, the import statement returns an object whose contents are defined by the file init.py at the top level of the package directory hierarchy. For example, to make only the function squareAndAdd() available when importing the package pypackage, the contents of init.py should be similar to the following.

[0321] This logic could be in init.py:

[0322] from.exports import squareAndAdd

[0323] The Python ecosystem has no direct equivalent to JavaScript's browserify or webpack. Dependencies are resolved at runtime by searching for and loading modules and packages from the module search path. Application dependencies can be better encapsulated by creating a virtualenv. A virtualenv includes all the dependencies of the application, and an application executed within a virtualenv modifies the module search path so that only the versions of the dependencies installed within the virtualenv are visible. The versions of the dependencies to be installed in the virtualenv are specified via a requirements.txt file or, alternatively, a Pipfile in conjunction with the pipenv utility.

[0324] A Python MLE module is a zip file that contains Python modules or packages, as well as all or some of the dependencies installed in a virtualenv. The bundled dependencies are placed in a.bundleddeps directory at the top level of the deployed zip. When the MLE module is executed, the bundled dependencies are placed on the module search path. Any unbundled dependencies should be satisfied via in-language module imports.

[0325] The SIGNATURE clause of a call specification can reference any function defined in a Python MLE module:

[0326] · If a Python MLE module contains Python modules, then this includes all functions defined in that module, and

[0327] · If a Python MLE module contains Python packages, then this includes functions defined by the package at the top level (via its init.py file) or by any of its submodules or subpackages.

[0328] Functions in submodules or subpackages can be referenced using Python's usual dot notation (e.g., for the example package pypackage discussed above, exports.squareAndAdd). When calling such a call specification, the MLE loads the named module or package in a manner similar to a Python import statement, looks up the named function in the returned module object, and calls it. Note that a call specification cannot reference functions defined in any of the bundled dependencies.

[0329] 18.8 JAVA MLE Modules

[0330] The Java MLE module contains Java modules. Java modules are a better way to encapsulate Java code. Specifically, a Java module can contain one or more Java packages. By default, the packages defined in a Java module are internal to the module. Only those packages that are explicitly exported (by marking them in the module's module-info) can be accessed from outside the module. For example, a Java module (say, jmodule) can contain two packages, com.oracle.jmodule.dependencies and com.oracle.jmodule.exports, each with a single class, as shown below.

[0331] This logic can be Helpers.java:

[0332]

[0333] This logic can be Exports.java:

[0334]

[0335] Among them, the package com.oracle.jmodule.exports can be exported via the module-info.java file located at the top level of the module:

[0336] This can be module-info.java:

[0337] module jmodule{

[0338] exports com.oracle.jmodule.exports;

[0339] }

[0340] A Java module can require other Java modules. For example, a Java module (say, moduleA) can require another Java module (say, moduleB) by including the appropriate requires directive in its module-info:

[0341] module moduleA{

[0342] requires moduleB;

[0343] }

[0344] Then, when ModuleA is executed, ModuleB should exist on the module path, and ModuleA can access any packages exported by ModuleB.

[0345] The Java MLE module is a zip file that contains the Java module and some or all of the modules it depends on. These bundled dependencies are placed in the.bundleddeps directory at the top level of the deployed zip and are placed in the module path when the MLE module is executed. Any unbundled required modules should be obtained via in-language module imports.

[0346] The SIGNATURE clause of a call specification can reference any public static method of a class in the exported packages of a Java MLE module. For the example shown above, the function should be referenced using its fully qualified name (e.g., com.oracle.jmodule.exports.Exports.squareAndAdd). When calling such a call specification, the MLE loads the named class and calls the specified static method.

[0347] 18.9 Creation of Call Specifications

[0348] By creating PL / SQL call specifications for them, the functions exported by a deployed MLE module can be made available for calls from PL / SQL and SQL. These MLE functions can then be called from anywhere that a PL / SQL function or procedure can be called (e.g., in an SQL query, from a PL / SQL program, including anonymous blocks, as a virtual column).

[0349] Let's look again at the example of the deployed module jsmodule described above. The MLE module jsmodule exports two functions: the function doNothing() accepts an input string argument and does not perform any action, while the function concat() accepts two string arguments as input and returns the concatenated string as the result.

[0350] Since doNothing() does not return anything, it is not possible to create a PL / SQL function for it. Instead, a PL / SQL procedure is created:

[0351] CREATE OR REPLACE PROCEDURE

[0352] doNothing(str IN VARCHAR2) AS MLE MODULE jsmodule

[0353] SIGNATURE 'doNothing(str string)';

[0354] The above call specification creates a PL / SQL procedure named doNothing() in the current user's schema. Executing this function executes the function doNothing() exported from the JavaScript module jsmodule. The MLE-specific clause MLEMODULE <module name> specifies the name of the MLE module that exports the underlying MLE language function. The SIGNATURE clause specifies the name of the exported function to be called (doNothing()) and its argument types. The types specified in the SIGNATURE clause are specific to the MLE language. MLE functions implemented in JavaScript use TypeScript types in the SIGNATURE clause. In this case, the function accepts a JavaScript string; the PL / SQL VARCHAR2 string is converted to a JavaScript string before calling the underlying JavaScript implementation.

[0355] Another exported function, concat(), can be used similarly to create a PL / SQL function:

[0356] CREATE OR REPLACE FUNCTION concat

[0357] RETURN VARCHAR2

[0358] AS MLE MODULE jsmodule

[0359] SIGNATURE ’concat(str1 string,str2 string)’;

[0360] In this case, the call specification additionally specifies the PL / SQL return type of the created function. The value returned by the JavaScript function concat() (string type) is converted to the RDBMS data type (VARCHAR2). The created procedures and functions can be called as normal:

[0361] SQL>CALL doNothing('unused');

[0362] SQL>SELECT concat('Hello,','World!') FROM dual;SELECT CONCAT('HELLO','World!') FROM DUAL

[0363] ------------------------------------------

[0364] Hello,World!

[0365] 18.10 Support for OUT and IN / OUT Parameters

[0366] Just like regular PL / SQL functions and stored procedures, MLE functions support IN / OUT and OUT parameters in addition to IN parameters. These are typically declared as IN / OUT and OUT parameters in the PL / SQL call specifications used for MLE functions. The handling of these parameters in the underlying MLE language implementation is language-specific.

[0367] Since JavaScript has no concept of output parameters, the JavaScript implementation instead accepts objects that wrap the parameter values. Specifically, the shape of these wrapper objects is described by the common interfaces InOut and Out (for IN / OUT and OUT parameters respectively) as follows.

[0368] InOut <t>Interface:

[0369] interface InOut <t>{

[0370] value: T;

[0371] }

[0372] Out <t>Interface:

[0373] interface Out <t>{value:T;

[0374] }

[0375] For example, an MLE function with a single VARCHAR2 IN / OUT parameter replaces all occurrences of World with Universe and returns the number of occurrences of World in the original string:

[0376] CREATE OR REPLACE PROCEDURE

[0377] substituteWorld(str INOUT VARCHAR2) RETURN NUMBER AS MLE MODULEinOutParamExample

[0378] SIGNATURE'substituteWorld(str InOut <string>)’;

[0379] The underlying JavaScript module bar can be implemented as follows:

[0380]

[0381] The CALL specification's SIGNATURE clause lists the parameter types of the JavaScript function as InOut <string>Therefore, the input VARCHAR2 value is converted into a JavaScript string, which is then wrapped in an object and passed to the JavaScript function substituteWorld().

[0382] 18.11 Call Specification for JAVASCRIPT MLE Modules

[0383] The SIGNATURE clause of the call specification can reference one of the exported functions of a JavaScript MLE module. When such a call specification is invoked, the MLE loads the module in a manner similar to the require() function: evaluates the contents of the module, looks up the named function in the module.exports object, and calls it.

[0384] 18.12 Call Specification for Python MLE Modules

[0385] The SIGNATURE clause of the call specification can reference any function defined in a Python MLE module:

[0386] · If the Python MLE module contains Python modules, then this includes all functions defined in that module, as well as

[0387] · If the Python MLE module contains Python packages, then this includes functions defined by the top-level package (via its __init__.py file) or by any of its submodules or subpackages.

[0388] Functions in submodules or subpackages can be referenced using Python's usual dot notation (e.g., for the example package pypackage discussed above, exports.squareAndAdd). When such a call specification is invoked, the MLE loads the named module or package in a manner similar to a Python import statement, looks up the named function in the returned module object, and calls it. Note that the call specification cannot reference functions defined in any bundled dependencies.

[0389] 18.13 Call Specification for JAVA MLE Modules

[0390] The SIGNATURE clause of the call specification can reference any public static method of a class in the exported package of a Java MLE module. For the example shown above, the function should be referenced using its fully qualified name (e.g., com.oracle.jmodule.exports.Exports.squareAndAdd). When such a call specification is invoked, the MLE loads the named class and calls the specified static method.

[0391] 18.14 Module Metadata

[0392] The MLE module can carry optional metadata in the form of a version string and free-form JSON value metadata. Both types of metadata are purely informational and do not affect the behavior of the MLE. When creating an MLE module, the version string can be specified:

[0393] CREATE MLE MODULE scott."validator"

[0394] LANGUAGE JAVASCRIPT

[0395] VERSION ’10.11.0’

[0396] AS module.exports.func=function(){...}

[0397] The JSON metadata of the MLE module can be set or replaced using the ALTER MLE MODULE DDL:

[0398] ALTER MLE MODULE mymodule SET METADATA

[0399] <json-valued-metadata>

[0400] The MLE does not fix specific usages of JSON metadata fields.

[0401] 18.15 Runtime State Isolation for MLE Call Specifications

[0402] PL / SQL calls to MLE functions via call specifications are executed in an execution context determined by the MLE module and are executed by the user on whose behalf the call is made. In a session, the MLE uses a dedicated execution context for each MLE module called from SQL or PL / SQL. The MLE also separates the execution contexts of MLE modules by user. All SQL or PL / SQL calls to MLE functions exported by the same module on behalf of the same user are executed in the same execution context during the session. When a user first calls a function exported by a module from SQL or PL / SQL in a session, the execution context for the MLE module is lazily created.

[0403] Thus, the runtime states of MLE modules executed on behalf of different users and with different privilege levels are completely separated. Moreover, the runtime states of separate MLE modules called from SQL or PL / SQL are completely separated.

[0404] This is best illustrated by an example with two MLE modules (ModuleA and ModuleB). ModuleA exports two functions func1() and func2(), while ModuleB exports a single function func3() (signature abbreviated):

[0405]

[0406]

[0407] All calls to func1() and func2() from SQL or PL / SQL executed on behalf of User1 use one execution context, while calls to the same functions from User2 use a separate execution context. Similarly, User1's calls to func3() use a separate execution context from the calls to func1() and func2() because func3() is exported by a different MLE module (ModuleB).

[0408] Thus, if the PL / SQL call specification for a function exported by an MLE module is declared with definer's rights (e.g., DDL), then there is only a single execution context for the module in the session because all executions occur under the definer's rights. On the other hand, for a call specification with caller's rights, each calling user will have a separate execution context.

[0409] Note that if an MLE module (e.g., ModuleB) is imported by another MLE module (e.g., ModuleA), then the code from ModuleB executes in the same execution context as ModuleA. In this case, the code of ModuleB is loaded in the execution context of ModuleA.

[0410] 18.16 INTER MLE Module Import

[0411] Functions exported by an MLE module can be called from SQL and PL / SQL using the call specification. Also, the functionality in an MLE module can be reused by other MLE language code outside of the MLE module itself. MLE language code in an existing execution context can import the code of an MLE module in the same language using the native import mechanism of the language.

[0412] The following is a JavaScript MLE module scott.hello that exports a function format:

[0413]

[0414]

[0415] Using the call specification, the MLE module scott.hello can be used directly from SQL and PL / SQL:

[0416] CREATE FUNCTION scott.hello_format(name IN VARCHAR2)

[0417] RETURNS VARCHAR2 AS MLE MODULE scott."hello"SIGNATURE

[0418] ’format’;

[0419] SELECT scott.hello_format(’Larry’) FROM dual;

[0420] The query returns the string "Hello, Larry!".

[0421] The MLE JavaScript runtime provides the familiar JavaScript function require() to import JavaScript MLE modules. When the call require('hello') is executed, MLE resolves the import name 'hello' to the MLE module pattern object scott.hello, loads the source attached to scott.hello as a UMD module, and returns the result.

[0422] Use the environment mechanism described elsewhere in this article to resolve the import name to an MLE module pattern object. In the same way, the functionality of the MLE module scott.hello can be used by another MLE module. Here, the code in the MLE module scott.mymodule imports scott.hello:

[0423]

[0424] Use the environment scott.myenv to resolve the import name "hello” to the MLE module pattern object scott.hello. The resolution of import names by the environment is described elsewhere in this article.

[0425] Then the call spec scott.print_hello can be called from PL / SQL:

[0426] BEGIN

[0427] scott.print_hello('Larry');

[0428] END;

[0429] Executing this PL / SQL block produces the following output:

[0430] Hello,Larry!(call spec)

[0431] 18.17 Module Import and Execution Context

[0432] When the code of the MLE module is imported, it runs in the same execution context as the importing code. In the first scenario, a function exported by the MLE module hello is called from SQL in the format. Here, the code of the MLE module hello runs in a dedicated execution context. In the second scenario, the code of the MLE module hello is imported by the MLE module mymodule. Here, the function printHello exported by the module mymodule is called from PL / SQL. Therefore, according to REF, mymodule executes in a dedicated execution context. On the other hand, the module hello is imported from mymodule into the existing execution context.

[0433] The use of execution contexts by MLE can be summarized as follows:

[0434] · Calls to functions exported by an MLE module from SQL and PL / SQL are executed in a dedicated execution context for the MLE module and for the user on whose behalf the call is being made.

[0435] · An MLE module imported by MLE language code in an existing execution context runs in the same execution context as the importing code. The code in the imported module runs with the same privileges as the importing code.

[0436] 18.18 Context

[0437] In this example implementation, the environment or context can be a guest virtual environment. MLE uses execution contexts to execute MLE language code. As mentioned earlier, execution contexts are used both for executing dynamic MLE fragments and for executing calls to PL / SQL call specifications. MLE allows certain characteristics of the execution context to be configured via the environment. The execution context can be configured to use a specific environment. The execution context is then set with all the characteristics defined in the environment. Specifically, the environment allows language options to be set in order to customize the runtime of the MLE language in the execution context and to enable the import of specific MLE modules and the management of dependencies in the execution context.

[0438] The following describes how to create an environment and how to use the environment to define the characteristics of a dynamic MLE context and the execution context for MLE modules. It also describes how to use the environment to configure language options and enable MLE module imports. An environment is a first-class schema object that can manage itself and be reused across multiple execution contexts. An environment can be created using the CREATE MLE ENV DDL statement. It can be created as a fresh, empty environment:

[0439] CREATE MLE ENV scott."myenv";

[0440] Alternatively, the environment can also be created as a separate copy of an existing environment.

[0441] CREATE MLE ENV scott."myenv"CLONE <other-env>;

[0442] Note that when cloning an environment, subsequent modifications to the original environment do not propagate to the cloned environment. Cloning of environments is particularly useful for creating modified versions of the default environments provided by MLE.

[0443] Contextual features defined in the environment cannot be modified for an existing execution context. Only the environment settings at the time of context creation are valid for the execution context. The context for MLE module calls from SQL or PL / SQL is implicitly created as needed.

[0444] 18.19 Default Environments

[0445] MLE provides a default environment object that specifies the default features of the execution context. If no environment is explicitly specified on an MLE module, then the default environment is used implicitly. The default environment sets the default language option. It also provides an import map for the built-in MLE modules described elsewhere in this document.

[0446] At the database level, the default environment is defined using the initialization parameter MLE_DEFAULT_ENV. This parameter specifies the name of the schema object for the default environment. Access to the default environment needs to be granted to PUBLIC. The parameter MLE_DEFAULT_ENV can be modified during a session using the ALTER SESSION SET MLE_DEFAULT_ENV = <...> command. As with any initialization parameter, the current effective setting of MLE_DEFAULT_ENV can be obtained using the SHOW PARAMETERS command or the v$parameters view. Except for the first version of MLE, future versions may configure a new default environment, for example, which sets new language options or brings new built-in MLE modules. However, this will only provide a new environment object and change the default setting for MLE_DEFAULT_ENV. The schema objects for the previous default environment will remain in place. Existing MLE modules reference specific schema objects and are not affected by the new default environment.

[0447] 18.20 Specifying the Environment on an MLE Module

[0448] MLE modules called from PL / SQL via the call specification execute in their own execution context. Each MLE module specifies the environment that defines the execution context features when called from PL / SQL. However, note that when an MLE module is imported by another MLE module, the environment defined for the MLE module is not used.

[0449] The environment for an MLE module is defined when the MLE module is created using the CREATE MLE MODULE DDL statement:

[0450] CREATE MLE MODULE mymodule LANGUAGE JAVASCRIPT

[0451] ENV scott."myenv" AS...;

[0452] If the ENV clause is omitted, the default environment is used. When an MLE module is created, the environment (either explicitly or implicitly specified) is stored as part of the module definition. If an MLE module is created without explicitly specifying an environment, selecting a new default environment at the instance or session level has no effect on the MLE module. This allows MLE to provide a new default environment in future releases without breaking application code. Existing MLE modules need to be modified to explicitly use the new environment. The environment of an existing MLE module object can be changed using the ALTER MLE MODULE command:

[0453] ALTER MLE MODULE mymodule ENV myenv

[0454] 18.21 Language Options

[0455] MLE allows customization of the MLE language runtime by setting language options. For example, language options can enable or disable built-in functions not covered by the language standard. They can also be used to select a specific version of the language standard. MLE language options can be directly mapped to GraalVM language options. However, MLE only allows a whitelisted subset of GraalVM language options that are considered stable, user-facing, and supported.

[0456] Configure language options for the execution context via the language options on the environment. Every execution context created sets all the language options defined in its environment. Language options are defined in the environment using the ALTER MLE ENV DDL statement. For example, an existing environment can be modified to enable the JavaScript "strict" mode that configures the Graal JavaScript language option js.strict as follows:

[0457] ALTER MLE ENV scott."myenv" SET LANGUAGE OPTIONS

[0458] 'js.strict = true';

[0459] The SET LANGUAGE OPTIONS clause replaces the existing language options configured in the environment. Multiple language options can be set to <option-name> ＝ <option-value>A comma-separated list of pairs.

[0460] 18.22 Import Resolution

[0461] The code of the MLE module can be imported in an existing execution context. Recall the above example of importing another MLE module using the JavaScript require() function. In order to execute the call to require(), MLE needs to resolve the import name "hello" to the schema object scott.hello. This requires a mapping from the import name to the schema object.

[0462] The environment maps import names to MLE module schema objects. The environment defines the MLE modules that can be imported in an execution context using the environment, and the import names that can be used to import them. Specifically, assume an environment that contains a mapping from the import name "hello" to the MLE module scott.hello. In any execution context using this environment, JavaScript code can execute require('hello') and load the UMD module contained in scott.hello. Import mappings can be added to the environment using the ALTER MLE ENV DDL statement. For the above example, the import name "hello" is added to the environment defined above:

[0463] ALTER MLE ENV scott."myenv"

[0464] ADD IMPORT hello MODULE scott."hello";

[0465] Import names in the environment must be unique. If an import name is added to an environment that already contains that name, an error will be thrown. The environment defines the complete set of MLE modules that can be imported in a given execution context. The environment must explicitly include all transitive dependencies.

[0466] The environment decouples the import name from the actual MLE module. By updating the environment, the import name defined in the environment can be redirected to a new MLE module. This allows new versions of dependencies to be introduced. It is the responsibility of the environment owner to ensure that the new version of the dependency is compatible with the code using the environment. Using the ALTER MLE ENV command, import mappings can be removed from the environment or modified to point to a different MLE module.

[0467] 18.23 Import Names for JAVASCRIPT

[0468] The JavaScript MLE module is a single UMD module. In the MLE JavaScript runtime, the environment defines the search path for UMD modules: any import name defined in the environment that maps to a JavaScript MLE module (i.e., the UMD module) can be resolved with require. For example, executing require('validator') in the MLE JavaScript runtime first consults the environment of the execution context to find the mapping for the import name validator. If the mapping references a JavaScript MLE module (e.g., scott.validator), then the UMD module contained in that MLE module is retrieved, loaded by the UMD module loader, and the resulting value is returned. If the mapping for the import name validator either does not exist or references an MLE module in a different MLE language, then a PL / SQL runtime error is raised.

[0469] 18.24 Module Import for Python

[0470] A Python MLE module is either a single Python module or a Python package. When creating an execution context, the virtual environment is used as follows: for all mappings in the virtual environment that reference a Python MLE module, the code unit (i.e., the.py module or.zip packaged package) is extracted and placed in a directory in the virtual file system of the execution context under the import name used in the mapping. Subsequently, the sys.path search path of the Python engine is extended to include all these directories. Thus, the resolution of names on Python imports works according to the normal Python rules based on sys.path.

[0471] 18.25 Built-in MLE Modules

[0472] MLE provides built-in modules. A prominent example is the MLE SQL driver. MLE can dispose of built-in modules in a similar manner to user-defined MLE modules, using the same import mechanism. The only difference is that built-in modules are associated with the sys schema.

[0473] 18.26 Creating an MLE Language

[0474] A new MLE language can be added to the database using the CREATE MLE LANGUAGE DDL:

[0475] CREATE MLE LANGUAGE <schema>.]MYLANGUAGE;

[0476] The MLE versions included in the database should support the added languages. MLE language objects are created in different MLE namespaces. Creating a new MLE language in one's own schema requires the CREATE MLE LANGUAGE privilege, while creating a new MLE language in any schema requires the CREATE ANY MLE LANGUAGE privilege.

[0477] 18.27 Deleting an MLE Language

[0478] An MLE language can be deleted from the database using the DROP MLE LANGUAGE DDL:

[0479] DROP MLE LANGUAGE <schema>.]MYLANGUAGE;

[0480] To drop the MLE language requirement in its own schema, the DROP MLE LANGUAGE privilege is required, while to drop the MLE language requirement in any schema, the DROP ANY MLE LANGUAGE privilege is required.

[0481] 18.28 Management Environment

[0482] An environment can be created using the CREATE MLE ENV DDL statement. It can be created as either a brand-new empty environment or by cloning an existing environment. Cloning an environment creates an independent copy that is not affected by subsequent changes to the original environment. An existing environment can be dropped using the DROP MLE ENV DDL statement as follows.

[0483] DROP MLE ENV <schema> .] <name>;

[0484] The existing environment can be modified using the ALTER MLE ENV DDL statement. Mappings for import names can be added, removed, or changed. Additionally, language options can be set.

[0485] The ADD IMPORT clause adds a new mapping from the import name to an MLE module schema object. If the environment already contains the import name, an error is thrown.

[0486] The DROP IMPORT clause removes the import name from the environment. If the environment does not contain the specified import name, an error is thrown.

[0487] ALTER IMPORT modifies the import mapping so that the import name refers to a different MLE module schema object. If the environment does not contain the import name, an error is thrown.

[0488] The LANGUAGE OPTIONS clause in the MLE environment specifies the language options to be set for all execution contexts created using this environment. The language options are specified as a string literal consisting of comma-separated key-value pairs. The language options are only profiled at runtime when an execution context is created using the MLE environment. If the language options string is invalid (invalid format, unsupported option) when creating the context, an error is thrown.

[0489] 18.29 Creating an MLE Module

[0490] Use the CREATE MLE MODULE DDL to create an MLE module:

[0491] CREATE[OR REPLACE]MLE MODULE <module-schema> .] <name>

[0492] LANGUAGE <language-schema> .] <mle-language>[ENV

[0493] <language-schema> .] <mle-env>

[0494] [VERSION’ <version-string>’]

[0495] {USING

[0496] {BFILE(<directory object name>,<server file name>)|

[0497] {CLOB|BLOB|BFILE}<selection clause>}|

[0498] AS<module text>}

[0499] The CREATE OR REPLACE clause specifies that a new MLE module should be created (CREATE) or an existing MLE module should be replaced (CREATE OR REPLACE).

[0500] If an MLE module with the given name already exists, then CREATE MLE MODULE (without the REPLACE clause) throws an error. Use CREATE OR REPLACE MLE MODULE, which replaces the existing module if it exists or creates a new module otherwise. When replacing an MLE module, there is no need to re-grant privileges on it.

[0501] Users need the CREATE MLE MODULE privilege to create or replace an MLE module in their own schema and the CREATE ANY MLE MODULE privilege to create or replace an MLE module in another user's schema.

[0502] The name of the module to be created can be fully qualified, that is, it includes both the schema and the name of the module created within that schema. If no schema is specified, then the module is created in the current user's schema. <module-schema> 、 <name> 、 <language-schema>And <mle-language>is automatically converted to uppercase, unless enclosed in double quotes. As with the MLE language, MLE modules are created in the MLE namespace.

[0503] The LANGUAGE clause specifies the MLE language of the module being created. The language specified should be one of the languages created via the CREATE MLE LANGUAGE DDL. If an unsupported MLE language is used, then an error is thrown.

[0504] The optional ENV clause specifies the MLE environment of the module being created. If the specified environment mode object does not exist, then an error is thrown.

[0505] The optional VERSION clause specifies the version string to be used for the MLE module.

[0506] The USING clause enables the creation of an MLE module from code contained within a CLOB, BLOB, or BFILE.

[0507] The BFILE clause specifies the directory (<directory objectname>) and file name (<server_file_name>) of the file holding the content of the MLE module to be deployed. The directory object should have been created using, for example, the CREATE DIRECTORY statement.

[0508] The CLOB|BLOB|BFIL clause specifies a subquery whose result should be a single row and column of the specified type (CLOB, BLOB, or BFILE) holding the content of the MLE module to be deployed. The CLOB option is only available if the deployed MLE module contains only text data. This is true for JavaScript, which is the only MLE language currently supported, but may not be true for other MLE languages added in the future. For MLE modules contained in BLOBs and BFILEs, it is assumed that any text data is encoded in the database character set.

[0509] The AS clause is used to specify the content of the deployed MLE module as a sequence of characters inline in the DDL statement. As with CLOBs, the AS clause is only available if the source of the MLE module contains only text data. The sequence of characters should not be enclosed in quotes. Instead, the sequence of characters is delimited only by the end of the DDL statement.

[0510] Use the DROP MLE MODULE DDL to delete a previously deployed MLE module:

[0511] DROP MLE MODULE <schema> .] <name>

[0512] The DROP statement specifies the name of the module to be deleted and, optionally, the schema. If no schema is specified, the schema of the current user is assumed. If the module to be deleted does not exist, the DROP MLE MODULE statement throws an error.

[0513] The attributes of a deployed MLE module can be assigned or changed via ALTER MLE MODULE DDL:

[0514] ALTER MLE MODULE <schema> .] <name>SET

[0515] {ENV <mle-env>|METADATA <json>}}

[0516] The ALTER MLE MODULE statement specifies the name of the module to be changed and optionally the schema. If no schema is specified, the current user's schema is assumed. The ALTER MLE MODULE statement throws an error if the module does not exist or invalid attributes are specified.

[0517] The SET ENV clause configures a new environment for the MLE module. Any execution context subsequently created for the MLE module is configured according to the new environment. An error is thrown in the following cases:

[0518] · If the specified environment does not exist, an error is thrown.

[0519] · If the environment is not in the same schema as the MLE module being changed, an error is thrown.

[0520] 18.30 Creation of MLE Call Specifications

[0521] Functions exported by a deployed MLE module can be used to create PL / SQL call specifications that can be called from all locations where regular PL / SQL functions and procedures can be called. The creation of these call specifications uses the familiar CREATE FUNCTION and CREATE PROCEDURE syntax and some MLE-specific elements:

[0522] CREATE [OR REPLACE] {FUNCTION | PROCEDURE}

[0523] <schema>.]<call_spec_name>[(param_declaration[,]...)

[0525] [RETURN datatype]

[0526] [{invoker_rights_clause|DETERMINISTIC|

[0527] parallel_enable_clause|result_cache_clause}]

[0528] {AS|IS}MLE MODULE <schema>.]<module_name>

[0529] SIGNATURE’<function_name_in_module>[(

[0530] mle_param_declaration)]’;

[0531] Most components of the CREATE FUNCTION and CREATE PROCEDURE statements have the same semantics as their counterparts when creating a PL / SQL UDF or stored procedure:

[0532] OR REPLACE specifies that if the function already exists, then the function should be recreated. This clause can be used to change the definition of an existing function without having to drop, recreate, and re-grant the object privileges that previously granted the function. Users who were previously granted privileges on the redefined function / procedure can still access the function without having to re-grant privileges.

[0533] schema specifies the schema that will contain the call specification. If schema is omitted, then the call specification is created in the current user's schema.

[0534] call_spec_name specifies the name of the call specification to be created. Call specifications are created in the default namespace, which is different from MLE modules and the MLE language that use the MLE namespace.

[0535] param_declaration specifies the parameters of the call specification.

[0536] The RETURN data type is only used for UDFs and specifies the data type of the function's return value. The return value can have any data type supported by PL / SQL. Only specify the data type; length, precision, or scale information should be omitted. The invoker_rights_clause specifies whether the function is invoker rights or definer rights.

[0537] AUTHID CURRENT_USER creates an invoker rights function, i.e., the function executes with the privileges of CURRENT_USER.

[0538] AUTHID DEFINER creates a definer rights function, i.e., the function / procedure executes with the privileges of the owner of the schema in which the function / procedure resides, and the external name resolves in that schema. This is the default.

[0539] DETERMINISTIC is only for UDFs and indicates that the function returns the same result value when called with the same values for its arguments. As with PL / SQL functions, this clause should not be used for functions that access the database in any way that might affect the function's return result. If the database chooses not to re-execute the function, the results of doing so are not captured.

[0540] The parallel_enable_clause is only for UDFs and is an optimization hint indicating that the function can be executed from the parallel execution servers of a parallel query operation.

[0541] The MLE MODULE and SIGNATURE clauses are specific to MLE as follows. The MLE MODULE clause specifies the MLE module for the deployment that exports the underlying MLE language function for the call specification. The <module_name> provided is the name of the deployed MLE module that exports the MLE language function specified in the SIGNATURE clause and can be fully qualified or not. The specified module should always be in the same schema as the call specification being created. If the specified MLE module does not exist or is in a different schema from the call specification being created, an error is thrown.

[0542] The SIGNATURE clause contains all the information necessary to map the MLE function that will be created by this call specification to the specific function exported by the specified MLE module. In particular, it includes three pieces of information:

[0543] · function_name_in_module specifies the name of the exported function in the MLE module

[0544] · mle_param_declaration specifies the MLE language parameter types of the function (relative to the PL / SQL parameter types) (optional)

[0545] · function_name_in_module can include any alphanumeric characters as well as the underscore ('_') and period ('.').

[0546] Note that the parsing and resolution of the SIGNATURE clause occur lazily when the MLE function is first executed. Any parsing or syntax errors in the SIGNATURE clause are reported only at that time, not when the call specification is created.

[0547] mle_param_declaration has the following form:

[0548] mle_param_declaration::= [<argument_name> <mle-language-type>[,]...]

[0549] The MLE - language - type can be a built - in type of the MLE language (e.g., string or number for JavaScript) or a type provided by MLE (e.g., OracleNumber or OracleDate).

[0550] The mle_param_declaration can be completely omitted from the SIGNATURE clause. In this case, the default PL / SQL - MLE language - type mapping is used. The encoding used to specify the SIGNATURE clause should be the same as the database character set.

[0551] 19.0 Database Overview

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

[0553] Generally, 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 the nodes for executing the integrated software components, where the combination of software and computing resources is dedicated to providing a specific type of function on behalf of clients of the server. The database server controls and facilitates access to a specific database and processes requests from clients to access the database.

[0554] Users interact with the database server of the DBMS by submitting commands that cause the database server to perform operations on data stored in the database. The user can be one or more applications running on a client computer that is interacting with the database server. Multiple users can also be collectively referred to as users in this document.

[0555] The database includes data and a database dictionary, which are stored on a persistent memory mechanism such as a set of hard disks. The database is defined by its own separate database dictionary. The database dictionary includes metadata that defines the database objects contained in the database. In fact, the database dictionary defines most of the database. Database objects include tables, table columns, and tablespaces. A tablespace is a collection of one or more files for storing data for various types of database objects such as tables. If the data for a database object is stored in a tablespace, then the database dictionary maps the database object to the one or more tablespaces that hold the data for the database object.

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

[0557] A database command can be in the form of a database statement. In order for a database server to process a database statement, the database statement 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 the data stored within the database structure. For example, SELECT, INSERT, UPDATE, and DELETE are some examples of common DML instructions in some SQL implementations. SQL / XML is a common extension of SQL used when manipulating XML data in object-relational databases.

[0558] A multi-node database management system (such as System 110) consists of interconnected nodes that share access to the same database. Typically, the nodes are interconnected via a network and share access to a shared storage device to varying degrees, such as shared access to a set of disk drives and the data blocks stored thereon. The nodes in a multi-node database system can be in the form of a set of computers (e.g., workstations, personal computers) interconnected via a network. Alternatively, the nodes can be nodes of a grid consisting of server blades in the form of nodes interconnected with other server blades on a rack.

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

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

[0561] 19.1 Query Processing

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

[0563] A query can perform operations on data from source data objects row by row as the (one or more) objects are loaded, or on the (one or more) entire source data objects after the (one or more) objects have been loaded. The result sets generated by some operations can make the (one or more) other operations available, and in this way, the result sets can be filtered or narrowed down based on certain criteria, and / or joined or combined with the (one or more) other result sets and / or the (one or more) other source data objects.

[0564] A subquery is a part or component of a query that is distinct from the other (one or more) parts or (one or more) components of the query and can be evaluated separately (i.e., as a separate query) from the other (one or more) parts or (one or more) components of the query. The other or (one or more) parts or or (one or more) components of the query can form an outer query, which may or may not include other subqueries. A subquery nested within an outer query can be evaluated one or more times separately while computing the result for the outer query.

[0565] Generally, a query parser receives a query statement and generates an internal query representation of the query statement. Typically, the internal query representation is a collection of interconnected data structures that represent the various components and structures of the query statement.

[0566] The internal query representation can be in the form of a node graph, with each interconnected data structure corresponding to a node and a component of the query statement being represented. The internal representation is typically generated in memory for evaluation, manipulation, and transformation.

[0567] Hardware Overview

[0568] According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform the techniques, or can include digital electronic devices such as one or more application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) persistently programmed to perform the techniques, or can include one or more general hardware processors programmed to perform the techniques according to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices can also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to implement the techniques. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hard-wired and / or program logic to implement the techniques.

[0569] For example, Figure 18 is a block diagram of a computer system 1800 on which embodiments of the present invention can be implemented. The computer system 1800 includes a bus 1802 or other communication mechanism for conveying information, and a hardware processor 1804 coupled to the bus 1802 for processing information. The hardware processor 1804 can be, for example, a general purpose microprocessor.

[0570] The computer system 1800 also includes a main memory 1806 coupled to the bus 1802, such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by the processor 1804. The main memory 1806 can also be used to store temporary variables or other intermediate information during execution of instructions by the processor 1804. When stored in a non-transitory storage medium accessible to the processor 1804, these instructions cause the computer system 1800 to become a special-purpose machine customized to perform the operations specified in the instructions.

[0571] The computer system 1800 also includes a read only memory (ROM) 1808 or other static storage device coupled to the bus 1802 for storing static information and instructions for the processor 1804. A storage device 1810, such as a magnetic disk, optical disk, or solid state drive, is provided and coupled to the bus 1802 for storing information and instructions.

[0572] The computer system 1800 can be coupled via a bus 1802 to a display 1812 (such as a cathode ray tube (CRT)) for displaying information to a computer user. An input device 1814 including alphanumeric keys and other keys is coupled to the bus 1802 for transmitting information and command selections to the processor 1804. Another type of user input device is a cursor control 1816 (such as a mouse, trackball, or cursor direction keys) for transmitting direction information and command selections to the processor 1804 and for controlling cursor movement on the display 1812. Such input devices typically have two degrees of freedom in 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.

[0573] The computer system 1800 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that in combination with the computer system causes or programs the computer system 1800 to be a special-purpose machine. According to one embodiment, the computer system 1800 performs the described techniques in response to execution by the processor 1804 of one or more sequences of one or more instructions contained in the main memory 1806. These instructions can be read into the main memory 1806 from another storage medium, such as the storage device 1810. Execution of the instruction sequence contained in the main memory 1806 causes the processor 1804 to perform the processing steps described herein. In an alternative embodiment, hardwired circuitry may be used in place of or in combination with software instructions.

[0574] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a particular fashion. Such storage medium may include non-volatile media and / or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid state drives such as the storage device 1810. Volatile media includes dynamic memory such as the main memory 1806. Common forms of storage media include, for example, floppy disks, flexible disks, hard disk drives, solid state drives, magnetic tape, or any other magnetic data storage medium, CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, RAM, PROM, and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge.

[0575] Storage media is different from transmission media but can be used in combination with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire, and fiber optics, including the wires that comprise the bus 1802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0576] A variety of forms of media can participate in conveying one or more sequences of one or more instructions to the processor 1804 for execution. For example, the instructions can initially be carried on a disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 1800 can receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector can receive the data carried in the infrared signal, and appropriate circuitry can place the data on the bus 1802. The bus 1802 transfers the data to the main memory 1806, and the processor 1804 retrieves and executes the instructions from the main memory 1806. The instructions received by the main memory 1806 can optionally be stored on the storage device 1810 before or after being executed by the processor 1804.

[0577] The computer system 1800 also includes a communication interface 1818 coupled to the bus 1802. The communication interface 1818 provides two-way data communication coupled to a network link 1820, where the network link 1820 is connected to a local network 1822. For example, the communication interface 1818 can be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a corresponding type of telephone line. As another example, the communication interface 1818 can be a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN. A wireless link can also be implemented. In any such implementation, the communication interface 1818 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0578] The network link 1820 typically provides data communication through one or more networks to other data devices. For example, the network link 1820 can provide a connection through the local network 1822 to a main computer 1824 or to a data device operated by an Internet Service Provider (ISP) 1826. The ISP 1826 in turn provides data communication services through the global packet data communication network (now commonly referred to as the "Internet" 1828). Both the local network 1822 and the Internet 1828 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through the various networks and signals on the network link 1820 and through the communication interface 1818 (which carry digital data to and from the computer system 1800) are example forms of transmission media.

[0579] The computer system 1800 can send messages and receive data, including program code, via one or more networks, network link 1820, and communication interface 1818. In an Internet example, the server 1830 can send the requested code for an application program via the Internet 1828, ISP 1826, local network 1822, and communication interface 1818.

[0580] The received code can be executed by the processor 1804 when received, and / or stored in the storage device 1810 or other non-volatile memory for later execution.

[0581] Software Overview

[0582] Figure 19 is a block diagram of a basic software system 1900 that can be used to control the operation of the computing system 1800. The software system 1900 and its components, including their connections, relationships, and functions, are merely exemplary and are not meant to limit the implementation of one or more example embodiments. Other software systems suitable for implementing one or more example embodiments may have different components, including components with different connections, relationships, and functions.

[0583] The software system 1900 is used to direct the operation of the computer system 1800. The software system 1900, which can be stored on the system memory (RAM) 1806 and the fixed storage device (e.g., hard disk or flash memory) 1810, includes a kernel or operating system (OS) 1910.

[0584] The OS 1910 manages the low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more applications represented as 1902A, 1902B, 1902C... 1902N can be "loaded" (e.g., transferred from the fixed storage device 1810 to the memory 1806) for execution by the system 1900. Applications or other software intended to be used on the computer system 1800 can also be stored as downloadable computer-executable instruction sets, e.g., for downloading and installation from an Internet location (e.g., a web server, app store, or other online service).

[0585] The software system 1900 includes a graphical user interface (GUI) 1915 for receiving user commands and data in a graphical manner (e.g., "clicking" or "touch gestures"). In turn, these inputs can be operated on by the system 1900 according to instructions from the operating system 1910 and / or one or more applications 1902. The GUI 1915 is also used to display the operation results from the OS 1910 and one or more applications 1902, and the user can provide additional inputs or terminate the session (e.g., log off).

[0586] OS 1910 can execute directly on the bare hardware 1920 of computer system 1800 (e.g., (one or more) processors 1804). Alternatively, a hypervisor or virtual machine monitor (VMM) 1930 can be inserted between the bare hardware 1920 and the OS 1910. In this configuration, the VMM 1930 acts as a software "buffer" or virtualization layer between the OS 1910 and the bare hardware 1920 of the computer system 1800.

[0587] The VMM 1930 instantiates and runs one or more virtual machine instances ("guest machines"). Each guest machine includes a "guest" operating system (such as OS 1910), and one or more applications (such as (one or more) applications 1902) designed to execute on the guest operating system. The VMM 1930 presents a virtual operating platform to the guest operating system and manages the execution of the guest operating system.

[0588] In some cases, the VMM 1930 can allow the guest operating system to run as if it were running directly on the bare hardware 1920 of the computer system 1800. In these instances, the same version of the guest operating system configured to execute directly on the bare hardware 1920 can also execute on the VMM 1930 without modification or reconfiguration. In other words, the VMM 1930 can provide full hardware and CPU virtualization to the guest operating system in some cases.

[0589] In other cases, the guest operating system can be specifically designed or configured to execute on the VMM 1930 for increased efficiency. In these instances, the guest operating system "is aware" that it is executing on the virtual machine monitor. In other words, the VMM 1930 can provide para-virtualization to the guest operating system in certain cases.

[0590] A computer system process includes the allocation of hardware processor time, as well as the allocation of memory (physical and / or virtual), the allocation of memory for storing instructions executed by the hardware processor, for storing data generated by the execution of instructions by the hardware processor, and / or for storing the hardware processor state (e.g., the contents of registers) between allocations of hardware processor time when the computer system process is not running. Computer system processes run under the control of an operating system and can also run under the control of other programs executable on the computer system.

[0591] Cloud computing

[0592] This document generally uses the term "cloud computing" 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.

[0593] Cloud computing environments (sometimes referred to as cloud environments or the cloud) can be implemented in a variety of different 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 public. In contrast, a private cloud environment is generally only used by or within a single organization. A community cloud is intended to be shared by several organizations within a community; while a hybrid cloud includes two or more types of clouds (e.g., private, community, or public) bound together through data and application portability.

[0594] Generally speaking, the cloud computing model enables some of those responsibilities that might previously have been provided by an organization's own information technology department to instead be delivered as a service layer within the cloud environment for consumption by consumers (either 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 or within each cloud service layer can vary, but common examples include: Software as a Service (SaaS), where the consumer uses 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 the consumer 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., everything under the runtime execution environment). Infrastructure as a Service (IaaS), where the consumer can deploy and run any software applications, and / or provision processes, storage, networks, and other basic computing resources while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), where the consumer uses a database server or database management system running on cloud infrastructure while the DbaaS provider manages or controls the underlying cloud infrastructure and applications

[0595] The above basic computer hardware, software, and cloud computing environment are presented to illustrate the basic underlying computer components that can be used to implement one or more example embodiments. However, one or more example embodiments need not be limited to any particular computing environment or computing device configuration. Instead, according to the present disclosure, one or more example embodiments can be implemented in any type of system architecture or processing environment that those skilled in the art will understand to be capable of supporting the features and functions presented herein.

[0596] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive. The sole and exclusive indication of the scope of the invention, and what the applicant intends to be the scope of the invention, is the literal and equivalent scope of the set of claims that is issued from this application in the specific form of such claims, including any subsequent corrections. < / schema> ​< / schema> ​< / json> < / name> < / schema> < / name> < / schema> < / name> < / module-schema> ​ < / language-schema> ​ < / language-schema> < / name> < / module-schema> < / name> < / schema> < / schema> < / schema> < / option-name> < / string> < / string> < / t> < / t> < / t> < / t>

Claims

1. A computer-implemented method, comprising: Executing a first Data Definition Language (DDL) statement that generates a guest environment, the guest environment being for parsing dependencies of a first guest programming language and a second guest programming language that are not native to a database management system (DBMS), wherein the guest environment is defined in a database schema within the DBMS; Executing a second DDL statement that generates a first binding of a first name of the first dependency to a first guest module implemented in the first guest programming language within the guest environment; Executing a third DDL statement that generates a second binding of a second name of a second dependency to a second guest module implemented in the second guest programming language within the same guest environment; Executing a first Data Manipulation Language (DML) statement within the DBMS, the first DML statement causing logic including the following operations to be executed in the first guest programming language: Issuing a first request to access the first dependency by the first name from the first guest programming language, and Selecting and accessing the first guest module implemented in the first guest programming language from the first guest programming language using the first name and the first binding within the guest environment; Executing a second DML statement within the DBMS, the second DML statement causing logic including the following operations to be executed in the first guest programming language: Issuing a second request to access the second dependency from the first guest programming language, and Selecting and accessing the second guest module implemented in the second guest programming language from the first guest programming language using the same guest environment; 2. The method according to claim 1, further comprising: Issuing a third request to access the same first dependency by the same first name; Accessing the same first guest module based on the third request and the same first binding; Wherein: The third request is issued from the second guest programming language, and / or The first request and the third request are issued from different user accounts.

3. The method according to claim 1, further comprising executing a Data Control Language (DCL) statement for granting access to the guest environment to a user account.

4. The method according to claim 1, wherein the first DDL statement or the second DDL statement specifies: a version number of the guest programming language, configuration settings of the first guest programming language, and / or a resource loading path.

5. The method according to claim 1, further comprising executing a fourth DDL statement for replacing the first binding of the first dependency to the first guest module with a third binding of the same first dependency to a third guest module within the guest environment.

6. The method according to claim 1, wherein generating the guest environment includes generating a clone of an existing guest environment.

7. The method according to claim 1, wherein the first binding of the first dependency to the first guest module includes a binding of the name of the first dependency to the first guest module in a database dictionary.

8. A computer-implemented method, comprising: Execute a data manipulation language (DML) statement in a database management system (DBMS), the DML statement invoking a guest programming language to cause: a) Execute a request that is access-dependent from the guest programming language, and b) Retrieve the dependency from a virtual file system having multiple alternative implementation mechanisms, the multiple alternative implementation mechanisms including: A first implementation mechanism based on an archive file or an actual file system, and A second implementation mechanism based on a memory buffer containing the unpacked contents of the entire archive file or a column of a database table in the DBMS.

9. The method according to claim 8, wherein: Executing the DML statement that invokes the guest programming language includes executing the DML statement in a first database session of the DBMS; Retrieving the dependency from the virtual file system includes loading a first resource as the dependency into a memory buffer; The method further includes executing a second DML statement that invokes the guest programming language to cause the following operations to be performed in a second database session of the DBMS: Execute a second request that accesses the same dependency from the guest programming language, and Resolve the dependency to a second resource that is not the first resource.

10. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the steps recited in any one of claims 1-7 to be performed.

11. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the steps recited in any one of claims 8 and 9 to be performed.

12. A computer system, comprising: A memory configured to store instructions; And One or more processors configured to execute the instructions to cause the steps recited in any one of claims 1-7 to be performed.

13. A computer system, comprising: A memory configured to store instructions; And One or more processors configured to execute the instructions to cause the steps recited in any one of claims 8 and 9 to be performed.

14. A computer program product comprising instructions that, when executed by one or more processors, cause the steps recited in any one of claims 1-7 to be performed.

15. A computer program product comprising instructions that, when executed by one or more processors, cause the steps recited in any one of claims 8 and 9 to be performed.

Images