Migration Guidelines For Ensuring Object Model Uniqueness

The following use cases may prove beneficial for determining when a user should seek assistance from the Operations team to upgrade from an earlier version of the Ability Platform.

Use Case 1

Child clashes with parent.

The user is advised to contact the Operations team with a migration request.

After fixes are applied, object models built within this types tree will still be valid and can be safely used.

In the following diagram,

• Red = type definitions within the inheritance tree that should be fixed to assure the consistency of the 'tree'.

• Yellow = type definitions after the fix of their uniqueness.

• Green = type definitions within tree which are ready for migration.

Use Case 2

In the type definitions inheritance trees, the lowest nodes/child should be soft-deleted and their object models should be checked manually. For assistance, contact the Operations team.

Re-create object models after the soft-deleted type is appropriately fixed.

NOTE

The steps provided here can be run only by the operations team or by developers who have access to internal Cosmos DB explorer and have privileges to run Gremlin queries directly on the database or who have access to internal Mongo DB/Cosmos DB explorer and have privileges to run Mongo/Gremlin queries directly on the database. None of the queries can alter any data in the database, as these are all read-only queries.

Object Models Resolution

As referenced above, a soft-deleted type definition will allow you to keep all objects. You will still have the option to find and drop them one by one.