Description
I can see that the migration ID is the current date by default which leads me to believe that migrations are applied in order. However there is a lack of documentation of what happens if an out-of-order migration is identified.
For example image that my DB is at version 1. Then two developers make feature branches and add migrations 2 and 3. If 3 merges and migrates first what happens when migration 2 gets merged?
It seems that there are 2 major options here:
- Reject migration 2 ("Error: Out of order migration 2 for DB version 3.")
- Apply migration 2.
I think option 2 is generally preferable however it does cause complications if the two migrations conflict. If you are lucky you will get an error on conflict, however the rare case could be that you get a different result applying 3 then 2 as opposed to 2 then 3. This would lead in the production DB having a different schema than developer machines which could be a source of bugs.
1 is annoying upfront but can be fixed by manually renaming migration 2 to come after migration 3. However depending on the rate of change of your project this Compare and Set style work can quickly become tedious.
Either way the current behaviour should be documented.