Let's separate data migrations from schema ones? #6910
Unanswered
oliverbarnes
asked this question in
Ideas
Replies: 3 comments
-
Anyway, it seems to me that it is essential to test the data migrations whether we choose to separate them from the migrations or not. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I'm working on a slowly moving PR for this. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I've been using https://github.com/ilyakatz/data-migrate and it seems to work fine. I've seen a middleware that checks if there's any pending data migration, and it there's any it fails (so you can't run the app) It might be worth checking out! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Right now Decidim is using Rails migrations for both schema and data migrations, when Rails migrations are really meant to be used for schema migrations, and not data ones.
A lot of projects do the same since Rails doesn't really have a built-in way to handle data migrations, as these can vary a lot depending on your app and infrastructure and there's no one-size-fits-all solution for them. And it's easy to pop in arbitrary ruby code inside Rails migrations.
But data migrations can break on-going schema migrations, and deployments while at it, in different and unexpected ways. For instance, they use Rails models in them, which can change or even disappear over time. If an old data migration is run for some reason and the model's changed, it'll crash, and it'll either need to be updated or removed, they're harder to revert than schema migrations, it's messy.
Data migrations can be run while the app is already running, after schema migrations are done being applied. This can greatly reduce deployment downtime during destructive schema changes.
As @armandfardeau pointed out, if data migrations are run separately schemas be loaded through
rake db:schema:load
, bypassing schema migrations altogether and decreasing migration and deployment time even more, and making them less error prone.I'm probably missing other issues with running data and schema migrations together (and possibly some arguments in favor :) )
A couple of references:
https://thoughtbot.com/blog/data-migrations-in-rails
https://boringrails.com/articles/rails-database-migrations-strategy-how-to-manage-migrations-without-losing-your-mind/
And a possible tool we could use (I haven't researched exhaustively and there's probably a few options out there):
https://github.com/jasonfb/nonschema_migrations
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions