Do you stick to Phoenix (Ecto)'s default migrations without schema file?

You’re talking of phoenix in your post, but actually phoenix doesn’t handle any of that, ecto does.

About your mentioned advantages:

1. 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?

2. 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 support mix ecto.dump/mix ecto.load to 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.

3. 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.

Yes, it’s Ecto, you are right.

1, I actually edit seeds from time to time and when I do I always rebuild. I also rebuild a lot of times in development to simply start clean.

2, The point is not just one source of truth, but simply the ability to see it. Maybe I was just used to it. I am aware of dump/load that’s why I am not asking on how to mimick it, but rather what others actually do.

there is a people problem

…and I did not say otherwise, just saying what can happen. The point is that once the mistake is done, it stays there…

Thanks for your input, appreciate it!

I would also like to see such a functionality. Having one definition and ecto would just do whatever it needs to do in order to transform the current state of the DB to the desired state of the DB. Doing this during runtime would be even better (e.g. building structs/maps with the desired config on runtime and handling it off to ecto to transform the DB).

PS: I know this is highly controversial, but it has its uses.

I don’t see the difference between doing a

rake db:schema:load
or 
rake db:structure:load

and

mix ecto.load

and

mix ecto.dump

I do this all the time, I have a Rails app that is my source of truth, it has all the migrations, for running my tests on CI, I do a mix ecto.dump, commit it and in my CI-script then mix ecto.load.

I think an important difference between Ecto’s approach vs. Rails’ ActiveRecord approach is that Ecto requires you (for normal usage) to specify the structure of your table columns of your structs.
In ActiveRecord this happens implicitly, so the only place where you can reliably look them up is in the schema.rb, whose structure changes depending on how many migrations have already been executed.

Yes, but in my case I don’t really care about having a structure.sql to look at. I just don’t want to be dependent on migrations.