I like the way Ruby on Rails have where you’re unable to start an application if it have pending migrations. Why isnt it like that in Phoenix?
Phoenix does not know about migrations. Migrations are an ecto thing.
Okay so rather Ecto would be the one to stop the possibility of starting the app in such case?
You could however implement that on your own. In your application.ex check the migrations and error if there are pending migrations.
Why should it?
Who does even say that your phoenix application is using ecto at all?
? If you’re not using Ecto then Ecto wouldnt stop the app from running?
No, but ecto might be a dep of a dep of a dep, I’m not even using, and just because it thinks that there are pending migrations, why should it fail my start?
To be honest, in dev or test, it is your responsibility to run migrations when you create them. You can easily automate this whith aliases.
In Prod everything should be set up, that you migrations are run during deployment. It is a waste of time there to check if all migrations are run. Or how would you handle this in a hotcode upgrade? Where you will have a phase where either new code with old database is running or vice versa. There is no application start during which you could check. It is just how it works.
Also, most of the time in dev you are already running your application when changing/adding migrations. And due to autoreload you often don’t even realize to restart the application.
Ecto can do nothing about this issues.
It’s generally perfectly fine from Ecto perspective to apply changes to database while the application is running (there’s actually a lot of complexity in drivers to support this scenario). There are also good reason to do so (one might be simple rolling upgrades). So we can’t check for it in ecto and fail otherwise - it would cause failures in situations that are completely fine.
Yeah I guess that makes sense. Thanks for answering!