Guest Language Dependency Resolution in Multilingual Databases

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Modern database systems lack support for multiple programming languages, leading to challenges in package management, versioning, and access control, particularly due to discrepant approaches in JavaScript and Python ecosystems, and the integration of guest programming languages is hindered by monolithic source files and complex privilege models.

Innovation Solution

A multilingual engine (MLE) within the database management system (DBMS) executes guest programming languages like JavaScript and Python using GraalVM, allowing for modular deployment of guest modules with sandboxed execution and unified access control, enabling intra- and inter-language module imports through guest virtual environments and virtual file systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple programming languages are integrated into the database system, then language versatility and ecosystem compatibility are improved, but system complexity and dependency management difficulty increase

Engineering Contradiction:
Improvelanguage versatilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system segments the database environment into distinct virtual environments, each supporting a specific programming language ecosystem with its own dependency resolution rules, package management approach, and execution context. This allows multiple languages (JavaScript, Python, etc.) to coexist without interfering with each other's dependency management mechanisms.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A multilingual engine acts as an intermediary layer between the database core and guest programming languages. This mediator handles language-specific dependency resolution, package installation, and execution management, translating various language ecosystems' requirements into database-compatible operations while preserving language-specific behaviors.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of operation

If package dependencies are resolved through in-lining of source code, then dependency management is simplified, but file size and deployment complexity increase due to monolithic source files

Engineering Contradiction:
Improvedependency managementVSAvoiddeployment complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The system dynamically resolves package dependencies at runtime rather than statically in-lining all dependencies during build time. The dependency resolution process adapts to the specific virtual environment and language ecosystem, allowing flexible inclusion or exclusion of dependencies based on actual execution needs, thereby avoiding monolithic file generation.

Inventive Principle:
Principle #15Dynamics

3Adaptability or versatility

If different package versions are supported through versioning mechanisms, then library compatibility is improved, but privilege model complexity and access control difficulty increase

Engineering Contradiction:
Improvelibrary compatibilityVSAvoidaccess control complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system applies different privilege models and access control mechanisms locally to each virtual environment and language ecosystem. Each environment can have its own versioning strategy and access control rules tailored to that language's conventions, while the database's overall privilege model remains intact. This allows Python's single-version approach or JavaScript's multi-version NPM model without imposing a unified complex access control structure.

Inventive Principle:
Principle #3Local quality

Data Source

PatentEP4022457B1Dynamic resolution of dependencies for database guest languages
Publication Date: 2025.11.12 ORACLE INT CORP
  • EP4022457B1 patent drawingFigure 1
  • EP4022457B1 patent drawingFigure 2
  • EP4022457B1 patent drawingFigure 3

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.