Extension Field Naming Algorithm for De-normalized Views
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In development environments for business software architectures, extension fields added in de-normalized views often lead to naming collisions, which are not effectively addressed by current approaches, potentially breaking customer extensions during software upgrades.
Innovation Solution
A method that generates a unique and reproducible name for extension fields by using a reference field bundle from a metadata repository, combining the extension field name with a hashed value based on the business object and node names to avoid collisions, ensuring compatibility across system upgrades.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If extension fields are added to a business object model in a development environment, then the functionality and adaptability of the business object are improved, but naming collisions occur in de-normalized views causing reliability issues
Solution Approach 1:
The extension field name is segmented into multiple components: the original extension field name and a generated suffix. This segmentation allows the system to preserve the meaningful extension field name while adding a unique identifier through the suffix, thereby avoiding naming collisions in de-normalized views without compromising the adaptability of extension fields.
Solution Approach 2:
A suffix generation mechanism acts as an intermediary between the extension field definition and its representation in de-normalized views. This intermediary computes a suffix based on the business object name, node name, and extension field name, and appends it to the extension field name, thereby mediating the conflict between extension functionality and naming collision avoidance.
2Ease of operation
If a simple extension field naming approach is used, then ease of operation is improved, but naming collisions occur breaking customer extensions during upgrades
Solution Approach 1:
The system performs preliminary action by generating and appending a suffix to the extension field name during the extension field definition phase, before the extension is deployed to de-normalized views. This preliminary action ensures that the full unique name is established upfront, preventing naming collisions during upgrades while maintaining a simple extension field creation process for users.
Solution Approach 2:
The suffix generation mechanism operates autonomously based on the business object name, node name, and extension field name. This self-service approach automatically resolves naming conflicts without requiring manual intervention from developers, thereby maintaining ease of operation while ensuring stable and consistent extension field names across system upgrades.
3Ease of manufacture
If extension fields use generic names, then ease of manufacture is improved, but collisions between redundantly named nodes occur in de-normalized views
Solution Approach 1:
The extension field name is segmented into the original generic name and a generated suffix component. This segmentation allows developers to continue using simple, generic extension field names for ease of manufacture, while the suffix component automatically resolves naming collisions in de-normalized views, effectively managing the complexity of unique naming without increasing manufacturing difficulty.
Solution Approach 2:
A suffix generation mechanism serves as an intermediary that processes generic extension field names and transforms them into unique names by appending a computed suffix. This intermediary handles the complexity of collision resolution automatically, allowing developers to maintain simple extension field creation processes while the system manages the complexity of ensuring unique names in de-normalized views.
Data Source
AI summary
An extension naming approach for avoiding naming collisions in de-normalized view on a business object can include accessing a reference field bundle, which includes reference field(s) corresponding to a core business object defined in a core software platform of a software architecture, from a metadata repository. A user can define an extension to the business object based on the core business object, for example via a development environment. The reference field(s) can include a defined path from a node in a peripheral object to a corresponding node in the core business object. A unique and reproducible name for the extension field can be generated based on the reference field, and the extension field with the unique and reproducible name can be added to the business object and to a data model of the peripheral object.