3 ms·

We have a similar migration tool we built a long time ago, and this project has a bug that we had to address. When you have to branches that each have a migrat

We have a similar migration tool we built a long time ago, and this project has a bug that we had to address. When you have to branches that each have a migration, you end up with 2 copies of N_N+1.sql, or worse yet, things that subtly merge w/o error, meaning you have committed migrations that might not run. Or the conflict-resolution process cascades painfully as you "re-sequence" your migrations. We ended up moving to a solution based on a manifest file; there is a single migrations.json that enumerates the exact order in which migrations must be applied. It causes merge conflicts whenever you have migrations that need their "application order" resolved, and it's fixable just by re-arraning the manifest; no file renaming required. It's been pretty robust so far.

DoggettCK 11y ago
I've had similar problems with FluentMigrator, even though it orders things nicely using an attribute on the migration class that has a long value representing the order things should run in. I just use timestamps for when the migration was created, like 201509010034, and for the most part, things are great. Until we got a high priority ticket, and a migration with a later timestamp got pushed ahead of an earlier one, so it never gave us the option to migrate the earlier one. Easy fix was just to update the timestamp of the earlier migration when it finally got through QA, since they weren't dependent on each other, but things could've gotten really messy, so I'm not 100% happy with the way migrations currently work.
- apinstein 11y ago
  And that's exactly the point of the migrations.json manifest; you'll get a merge conflict whenever this happens, and all you need to do is resolve the order of named migrations in a JSON array. It works really well!
rpwilcox 11y ago
Yup, Rails had a similar problem back in 1.0 days where it had a sequential migration number. Then it moved to essentially date formatted migration names in 2.0 and that solved that. Your manifest idea seems interesting, have to remember that one...

DoggettCK 11y ago

I've had similar problems with FluentMigrator, even though it orders things nicely using an attribute on the migration class that has a long value representing the order things should run in. I just use timestamps for when the migration was created, like 201509010034, and for the most part, things are great. Until we got a high priority ticket, and a migration with a later timestamp got pushed ahead of an earlier one, so it never gave us the option to migrate the earlier one. Easy fix was just to update the timestamp of the earlier migration when it finally got through QA, since they weren't dependent on each other, but things could've gotten really messy, so I'm not 100% happy with the way migrations currently work.

apinstein 11y ago
And that's exactly the point of the migrations.json manifest; you'll get a merge conflict whenever this happens, and all you need to do is resolve the order of named migrations in a JSON array. It works really well!

rpwilcox 11y ago

Yup, Rails had a similar problem back in 1.0 days where it had a sequential migration number. Then it moved to essentially date formatted migration names in 2.0 and that solved that. Your manifest idea seems interesting, have to remember that one...