Migration script leaves Module and Models in inconsistent state

Robert Walter

Created January 17, 2018 08:55

We experienced the following issue after running both manually written and automatically generated migration scripts:

ERROR - tion.runtime.base.VersionFixer - Migration assistant detected inconsistency in language versions. Module my.module.namespace.solution [solution] uses language my.language.namespace.langName with version 3 while its model my.module.namespace.solution.Model uses this language with version 2

We are uncertain how this state comes about. We suspect it might have to do with using a devkit as a "used language" dependency + an additional language dependency to my.language.namespace.langName. The language in question (my.language.namespace.langName) was not part of the devkit, but might have been resolved nonetheless since extending languages have been part of the devkit.

Any hints on how the inconsistent state comes about would be appreciated.

5 comments

Maria Lebedeva

Created February 06, 2018 17:00

Hello, Robert!
What actions created automatically generated migrations scripts? Move concept refactoring? Or something else?

Robert Walter

Created February 07, 2018 08:24

Hi Maria,

yes, move concept refactoring created a PureMigrationScript.

We also experienced the error above applying manually written migrations only, thought.

Best,

Robert

Mihail Muhin

Created February 12, 2018 19:16

Hi, Robert,

I'm currently investigating the issue, but still can't reproduce it. If you could remember the steps to reproduce, this might be helpful.

It would also be helpful if we knew what are the migrations from version 1 and from version 2 (in languagemy.language.namespace.langName). Maybe I could provide some workaround then.

Regards,

Mihail

Robert Walter

Created February 12, 2018 21:15

Hi Mihail,

this is tough, unfortunately, because we encountered this in different contexts and only ever noticed it when the error message from my original message appeared in the console. So it is hard for us to deduct the causality when this happened exactly.

Obviously, we got into this state after one of us migrated our languages via a migration script, commited these changes and pushed them to the remote repo.

After another user pulled these changes, this error seemed to have occured.

We now don't use this process anymore ("migrating languages by executing the migration script once, pushing and pulling changes on other clients to migrate them as well). This seems to be a bad practice, right?

Robert

Mihail Muhin

Created February 15, 2018 17:58

Hi, Robert,

Thanks for the info.

Ok, I can now imagine how this could happen when using VCS. We have not yet implemented handling versions info in VCS integration (we planned this long ago, but still don't have free hands for this task). The idea is that the inconsistency should be reported to the user on merge/update and (if possible) missing migrations should automatically be run on the model.

>migrating languages by executing the migration script once, pushing and pulling changes on other clients to migrate them as well

I'm not sure I heard you aright, but we typically adhere to the following strategy in our team:

author of the migration pushes migration to master branch
if the migration affects much code, the author may tell this to the team, then he waits for anyone asking to wait (e.g. if anybody has a big difference with master in his branch, he might want to merge first, not to have a huge merge session)
when nobody blocks the migration, the author runs it on the project and pushes to master, notifying everyone about the update

Regards,

Mihail

Please sign in to leave a comment.