diff options
author | Olivier Lacan <hi@olivierlacan.com> | 2018-07-30 16:48:42 +0200 |
---|---|---|
committer | Olivier Lacan <hi@olivierlacan.com> | 2018-08-03 12:59:04 +0200 |
commit | 4a2d5efa949695ba2d62a05efd0c5822017855d3 (patch) | |
tree | 397d5078738a1608645d971dd0259d1608c8bf6f /guides/rails_guides | |
parent | 59c3ed1b3f90db197000e3867f255781a02412e7 (diff) | |
download | rails-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