You’re talking of phoenix in your post, but actually phoenix doesn’t handle any of that, ecto does.
About your mentioned advantages:
-
I’ve never had any problems with speed of migrating the db. Especially given full migrations from 0 to everything don’t happen all to often I’m not sure how relevant this metric even is. Do you have an concrete example?
-
You’ll have one source of truth in both options. Either with many migration scripts or with a structure.sql. The difference is one is more like event sourcing, where changes are stored and the result is implicit, but rebuildable, while the other is more like a crud db, where the latest state is stored, but history is lost.
In event sourcing if rebuilding state becomes a problem (for speed or other reasons) there’s the idea of snapshots, which save the state at certain times. Ecto does supportmix ecto.dump/mix ecto.loadto dump your current db schema and load it back into the db. You can use this to get a similar effect. This is probably how ruby is doing it. -
Once you use those you could delete the migrations leading up to the schema dump.
In my opinion consolidating migrations can make sense for as long as those parts have not yet hit production. But once they do they’re no longer useful, as you’re no longer dealing with just the plain schema, but also with data stored in those. A dumped structure.sql will not contain data migrations, but they are a very important part of not developing, but maintaining a production database. I’m aware that’s no longer the pure developer perspective, but when debugging issues you’ll need to find out how your db got into a certain state and it might not be a bug in your code, but it might have been a migration.
If you’re handling those necessary data migrations in code outside of your ecto migrations, then I guess you can just use mix ecto.dump/mix ecto.load.
P.S.: Colleagues putting logic in migrations, which doesn’t belong there is a people problem. Changing how migrations are handled is likely not a solution.
