Secondary Mappings Decouple ORM Code Changes from Schema Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In software development, source code changes often require cumbersome and impractical database schema updates, limiting the efficiency of implementing modifications and additions in database-backed applications.
Innovation Solution
The implementation of secondary mappings in Object Relational Mapping (ORM) systems allows source code changes to be made without immediate schema updates by annotating attributes for remapping to in-memory data structures, enabling dynamic re-mapping of operations and storing values in a designated column or shadow table, decoupling source code changes from schema updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If source code changes are made in database-backed applications, then new functionality and bug fixes can be implemented, but database schema updates are required which are tedious and impractical
Solution Approach 1:
The patent introduces a secondary mapping layer as an intermediary between the ORM system and the database schema. This secondary mapping enables code changes to be made without immediate schema updates by temporarily mapping attributes to in-memory data structures or shadow tables, thereby decoupling the source code from the database schema and eliminating the need for tedious manual schema updates
Solution Approach 2:
The patent creates shadow tables that are copies of the primary database tables. These shadow tables allow the system to store and manipulate data according to the new schema definition without immediately updating the primary database schema. The secondary mapping directs operations to these copied structures, enabling code changes to be tested and deployed independently of schema updates
2Productivity
If ORM systems are used to reduce code writing, then development efficiency improves, but the same limitation exists where schema updates are still required for code changes
Solution Approach 1:
The secondary mapping layer acts as an intermediary that enhances the ORM system's capabilities. It allows the ORM to continue generating less code while adding the flexibility to handle schema changes independently. The secondary mapping intercepts ORM operations and redirects them to appropriate targets (primary tables or shadow tables), maintaining productivity while enabling schema independence
3Reliability
If tight integration exists between source code and database schema, then data consistency is maintained, but every code change requires schema updates which reduces productivity
Solution Approach 1:
The patent segments the mapping relationship into primary mapping and secondary mapping. The primary mapping maintains the traditional tight integration with the database schema for data consistency, while the secondary mapping provides a decoupled layer that allows code changes without schema updates. This segmentation enables both data consistency and improved productivity to coexist
Data Source
AI summary
Systems and methods are described for using secondary mappings in an Object Relational Mapping (ORM) system to enable source code changes to be implemented and carried out without requiring updates to the database schema. In order to use secondary mappings, one or more attributes of an object in the ORM system are annotated to indicate that they are secondary mapped attributes. The annotation can indicate to the ORM system that the various operations (e.g. read operations, write operations) referencing attributes of the object may need to be remapped if the column for the attribute being referenced does not actually exist in the database. For example, if no column is directly mapped to the attribute being referenced, the ORM system can remap the operation to point to a secondary data structure (e.g. a map stored in-memory) that will be used to store the value for that attribute.