aboutsummaryrefslogtreecommitdiffstats
path: root/guides/rails_guides
diff options
context:
space:
mode:
authorOlivier Lacan <hi@olivierlacan.com>2018-07-30 16:48:42 +0200
committerOlivier Lacan <hi@olivierlacan.com>2018-08-03 12:59:04 +0200
commit4a2d5efa949695ba2d62a05efd0c5822017855d3 (patch)
tree397d5078738a1608645d971dd0259d1608c8bf6f /guides/rails_guides
parent59c3ed1b3f90db197000e3867f255781a02412e7 (diff)
downloadrails-4a2d5efa949695ba2d62a05efd0c5822017855d3.tar.gz
rails-4a2d5efa949695ba2d62a05efd0c5822017855d3.tar.bz2
rails-4a2d5efa949695ba2d62a05efd0c5822017855d3.zip
Document best practices with old migrations
The copy here is of course up for discussion but it feels like we need to address the issue of old migrations in the Migration guide because other than mentioning the canonical nature of schema.rb/structure.sql or the actual database compared to migration files, it seems like more guidance would help. Here's a sample of the kinds of question people seem to often ask about old Rails migrations: - https://stackoverflow.com/questions/20119391/delete-old-migrations-files-in-a-rails-app - https://www.reddit.com/r/rails/comments/4ayosd/compacting_migrations_files_or_delete_them/ - https://stackoverflow.com/questions/4248682/is-it-a-good-idea-to-purge-old-rails-migration-files - https://stackoverflow.com/questions/707013/is-it-a-good-idea-to-collapse-old-rails-migrations - https://stackoverflow.com/questions/1981777/rails-remove-old-models-with-migrations - https://stackoverflow.com/questions/3343534/rebase-rails-migrations-in-a-long-running-project The common theme seems to be: "I've got old migrations, should I keep them around on an old project?". My personal stance is that as long as migrations run and don't take too long do so, you should keep them around since it allows people working on the Rails project with you to seamlessly upgrade their local development database without having to do a `db:drop db:schema:load` and lose all their seed data. While writing down this suggested new section it felt like I was describing a very cumbersome process that could be address with a rake task like: ```bash rails db:migrate:remove VERSION=20121201123456 ``` It rollback to the version just before `20121201123456`, delete the migration file, and run `db:migrate` to get back to the latest migration. This of course doesn't address a situation when someone would want to delete or merge all migrations prior to a certain date, which is addressed by [squasher](https://github.com/jalkoby/squasher). I'm not sure this is something we want to encourage people to do. Although I feel like with more and more production Rails apps over 5-years old, it's definitely a concern we should address.
Diffstat (limited to 'guides/rails_guides')
0 files changed, 0 insertions, 0 deletions