Multilingual Engine for Database Guest Language Modularization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database management systems lack support for multiple programming languages, leading to difficulties in package management, library interference, and access control due to disparate approaches and fine-grained privilege models, which complicates the deployment and sharing of source code across different language ecosystems.
Innovation Solution
A multilingual engine (MLE) is introduced that allows for the transparent, modular, and configurable embedding of new guest programming languages within a database management system, using a data definition language (DDL) to register and manage guest modules and virtual environments, enabling interoperability and unified source logic management across languages.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If database systems support multiple programming languages with different package management approaches, then language ecosystem compatibility is improved, but system complexity increases
Solution Approach 1:
The patent introduces a language environment as an intermediary layer between the database system and multiple programming languages. This language environment provides unified management for package dependencies, versioning, and resolution across different languages (JavaScript, Python, etc.), allowing the database to support multiple languages without directly managing their disparate package management mechanisms. The language environment acts as a mediator that translates and reconciles different language-specific approaches into a unified system.
Solution Approach 2:
The system is segmented into distinct components: the core database system, the language environment layer, and individual language implementations. Each language ecosystem (JavaScript with NPM, Python with Pip) is maintained as a separate module within the language environment, allowing independent management of package dependencies, versioning strategies, and resolution mechanisms for each language without affecting others. This segmentation isolates complexity into manageable, independent units.
2Adaptability or versatility
If different object versions are supported in database schemas, then version control flexibility is improved, but query resolution complexity increases
Solution Approach 1:
The language environment serves as an intermediary that handles version resolution before queries reach the database optimizer. When multiple versions of database objects exist in different schemas, the language environment's package management system resolves which version should be used based on language-specific versioning rules and dependencies, providing a fully qualified name to the query optimizer and eliminating the need for it to handle version resolution complexity.
Solution Approach 2:
Version resolution is performed in advance by the language environment's package manager before the query execution phase. The package management system pre-resolves dependencies and determines the correct version of each object based on version constraints and compatibility rules, so that when queries are executed, the version ambiguity has already been resolved and the query optimizer receives clear, unambiguous object references.
3Reliability
If fine-grained privilege models are implemented across multiple languages, then access control precision is improved, but implementation complexity increases
Solution Approach 1:
The database's existing fine-grained privilege model is universalized to work across all programming languages through the language environment layer. The same privilege mechanisms (read, create, execute, drop, alter at system-wide, schema, and object levels) are applied uniformly to database objects regardless of which programming language is used to access them. This allows precise access control to be maintained while avoiding the need to implement separate privilege models for each language.
4Measurement precision
If source code is deployed in specific schemas with fully qualified names, then object reference accuracy is improved, but code portability decreases
Solution Approach 1:
The language environment acts as an intermediary that handles schema resolution and name qualification. Source code can use simpler, less qualified names, and the language environment's package management system automatically resolves these to fully qualified names with the correct schema prefixes based on the current language environment context. This allows code to maintain portability while the system ensures accurate object references through automatic qualification.
Solution Approach 2:
The schema resolution process is dynamic rather than static. The same unqualified or partially qualified name can resolve to different fully qualified names depending on the current language environment context, including which language is active, what schemas are available, and what version constraints apply. This dynamic resolution maintains code portability while ensuring accurate object references at execution time.
Data Source
AI summary
Herein are techniques that extend a software system to embed new guest programing languages (GPLs) that interoperate in a transparent, modular, and configurable way. In embodiments, a computer inserts an implementation of a GPL into a deployment of the system. A command registers the GPL, define subroutines for the GPL, generates a guest virtual environment, and adds a binding of a dependency to a guest module. In an embodiment, a native programing language invokes a guest programing language to cause importing intra- or inter-language dependencies. An embodiment defines a guest object that is 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 that include: an archive file or an actual file system, and a memory buffer or a column of a database table.