Nested Anchor support and extensions to Data Manager OMAS #6416
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR provides an extension to Data Manager OMAS and Database Integrator OMIS that allows the caller to build a schema of tables and columns independently from the database asset(s) and then attach them once complete. This reduces the workload on the open metadata ecosystem because LatestChange classifications are not maintained on the database assets while the tables and columns are being constructed. The original methods are still available so there is no impact on existing callers/connectors.
Database schema types
Database tables and columns are specialized types of Schema Attributes in open metadata. They are connected to a database asset via a RelationalDBSchemaType which is a specialized ComplexSchemaType. Data Manager OMAS has, in the past, managed the RelationalDBSchemaType internally in its createTableXXX and createViewXXXmethods. There are now methods to create the RelationalDBSchemaType explicitly and attach tables and views to it (no change is needed to database columns since they are attached to tables/views). Once the tables/views and their nested columns are created, there is another method to attach the RelationalDBSchemaType to either the database asset or the database schema asset.
For example this is the original code
and this is the new alternative
Nested anchor support
While the schema type is being constructed, all of the tables and columns are anchored on the RelationalDBSchemaType so that they can be deleted together. These anchors are established as part of the createEntity method.
When the RelationalDBSchemaType is attached to a database asset, its anchor is set to the GUID of the database asset. If the anchor GUID of all of the tables, views and columns where then updated to the database asset, much of the performance savings by building the schema separately would be lost. So the generic handlers have been updated so that it is able to honour nested anchors. This means that if the database asset is deleted, the attached schema type and its tables/views/columns are also deleted - as if they where all part of the same anchor.
I have also prevented LatestChange from being updated when an Anchors classification changes.
Template support
The ability to create elements using templates has been enhanced to support nested anchors. If the template uses nested anchors, these are copied for the new bean. However the copies are given the new top-level bean as the anchor. Effectively the nesting is not preserved in the new bean.
How Has This Been Tested?
New FVT tests have been added to the Data Manager FVT to exercise this function
Any additional notes for reviewers?