Database Container Delivery Infrastructure for Zero-Downtime Schema Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The challenge lies in updating Advanced Business Application Programming (ABAP) to natively support the evolving features and data formats of in-memory databases, as each new version introduces significant changes, making continuous redesign impractical.
Innovation Solution
A database container delivery infrastructure is introduced, which manages multiple schemas through a dependency model, allowing for logical and physical schema management, and uses orchestration and delivery infrastructures to ensure cycle-free dependencies and efficient deployment of database objects across different schema versions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If ABAP is updated to natively support new in-memory database features and data formats, then compatibility with the latest database versions is improved, but the complexity and effort required for continuous redesign increases
Solution Approach 1:
The patent introduces a schema mapping and query rewriting middleware that acts as an intermediary between the ABAP application layer and the in-memory database. This middleware translates tenant-specific logical queries into physical queries and maps logical schemas to physical schemas, allowing ABAP to work with evolving database features without requiring continuous redesign. The middleware handles the adaptation to new database versions, isolating the ABAP layer from database-specific changes.
Solution Approach 2:
The system segments the database architecture into multiple layers: the ABAP application layer, the query rewriting middleware layer, and the physical database layer. This segmentation allows each layer to evolve independently - the database can adopt new features while the ABAP layer remains stable, with the middleware handling the translation between them.
2Reliability
If multiple schema versions are managed simultaneously to support zero-downtime upgrades, then system availability is improved, but the complexity of managing dependencies and deployments increases
Solution Approach 1:
The system dynamically manages multiple schema versions, allowing schemas to be created, activated, and deactivated based on deployment needs. The schema mapping infrastructure dynamically resolves logical schema names to physical schema names, enabling seamless switching between versions without manual intervention. This dynamic approach supports zero-downtime upgrades by allowing new schemas to be prepared while existing schemas remain active.
Solution Approach 2:
New database schemas can be created and prepared in advance before being activated. The system allows developers to define new schemas with the latest database features, perform validation, and then activate them without interrupting the running system. This preliminary action enables smooth transitions between schema versions.
3Adaptability or versatility
If logical schema names are decoupled from physical schema names to enable machine-agnostic development, then portability is improved, but the complexity of schema mapping and resolution increases
Solution Approach 1:
The system creates a logical copy of the physical database schema structure that is independent of the underlying database implementation. Logical schema names serve as abstract representations that map to physical schema names through a mapping infrastructure. This copying approach allows developers to work with machine-agnostic logical names while the mapping infrastructure handles the translation to database-specific physical names.
4Speed
If in-memory databases are used to improve data access speed, then performance is improved, but the ability to maintain compatibility with traditional relational database features decreases
Solution Approach 1:
The query rewriting middleware provides universal compatibility by supporting both traditional relational database query patterns and in-memory database optimizations. It can rewrite queries to leverage in-memory capabilities while maintaining support for SQL standards and relational database features, making the system work efficiently with in-memory databases while preserving compatibility with existing ABAP applications designed for relational databases.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
In an example embodiment, software objects of a first database type are delivered to a first schema having a first physical name and stored in the software object database. A definition is created for the first schema including a logical name for the first schema. The first schema is activated by replacing, at a time subsequent to the first schema being delivered to the software object database, the logical name for the first schema stored in the definition with a physical name for the first schema.