Hello everyone,
currently we are trying to handle the following scenario:
In our application we use long-living documents/document-models. We now have to deal with the case that a change (e.g. the addition of a mandatory field) becomes necessary in production. In this case, the document model must be updated, and all existing documents in the model must also be migrated (e.g. a default value for the new mandatory field).
We understand the migration documented here as the solution to our problem.
The versioning described there clusters the associated MigrationSteps into a migration. A specification (apart from semantic numbering for sorting) is not made. A concrete connection to the model version (driven by the A12 update and maintained in the document-model header) probably does not exist. So we could give each migration its own version number. However, the framework also seems to introduce its own migrations in this way, which do not follow any apparent version scheme.
For example:
RelationshipMigrationStep = version 2.0.0
RelationshipLinkMigrationStep = version 3.0.0
… here is the gap
AttacRelationshipMigrationStephementsV2MigrationStep = Version 34.1.0
Even using the dataservices-server-init-app shouldn’t change anything about a possible version conflict between us and MGM. Is there a convention for assigning version numbers to avoid conflicts with MGM’s own migrations so that our migrations can coexist with them, and is the mechanism from the documentation actually the method of choice to implement our requirement?
Hi @mathias-early-ravine ,
Thanks for the excellent suggestion. I have created A12S-3169 where the DS team will enforce the DS versioning for migration steps and we will also use ordering so it will be clear which migration order are migration steps executed.
@tomas-thin-gale
Thank you for your reply! Unfortunately I do not have access to the MGM ticket management. Can you roughly estimate when the topic will be processed or in which data service version a solution can be expected at the earliest?
Hi @mathias-early-ravine,
2023.02 version will contain DS 35.0.0 where this will be fixed. This is planned to be released in February. There are no plans to port it to 2022.06-ext because the fix for it is breaking.
Hello @tomas-thin-gale,
I am a colleague of @mathias-early-ravine and continuing his work regarding this topic at the moment. We are starting to use the model migration and are required to do so. The question initially asked here by my colleague is still unanswered, which we would need answered in order for us to avert future clashes:
Which version range can we safely assign to the field “version” in a MigrationStep so that we will not collide with any A12 internal migrations?
I hope you can help us out here. Thanks in advance 
Best regards,
Kai Pfrötschner
Hi @anon51430998,
We have implemented strict ordering of migration steps and migration tasks in version 35.0.0 which is not yet released, We cannot port it to the older release lines because it is a breaking change. We would recommend using version ranges 34.4.0 - 34.10.0 for your migration steps. These versions will be acceptable even in the new DS artifact.
Answer is valid for DS versions 32.2 - 34.2