Managing type key changes on seed data

#1

We had a type A that extended another type B (Persistable), and we had a code that declares some seed data of the type A.
We decided to refactor type A to extended another type C which extends type B (the type key changed).
Now when provisioning the new code we get errors that complains about existing instances of A with the same id we want to provision:

{fileUrl:“meta://mycode/package.json”,lineNum:0,colNum:0,severity:“ERROR”,message:“[Message] createBatch failed due to multiple errors: \nTarget id: myid1, msg: The specified ID ‘myid1’ already exists for type A. Please change to a unique ID.“}

Since the provisioning is failing we can’t call A.removeAll() to remove the existing instance to replace them.
Is there a way to deal with this kind of refactoring without breaking all the database? I’m thinking about a “migration” types that could be triggered automatically on provisioning.

0 Likes

#2

This requires a complex migration. There is currently only support in SchemaMigrationCommon.insertNewBaseType to insert a new type at the base of the hierarchy but not in the middle. Without that, it would require upgrading using sql. To make that easier would require adding another similar function in SchemaMigrationCommon.

0 Likes

#3

Thanks @trothwein we finally found a solution using SchemaUpgrade using SQL UPDATE commands to change type_ident values on provisioning.

0 Likes

#4

@NabilKoroghli Great. Can you please file a ticket and explain what you ended up having to do so we can provide a platform feature so others won’t have to go through that?

0 Likes

#5

Improvement ticket opened!

0 Likes