|
|
|
|
|
by samwgoldman
3945 days ago
|
|
I have quite a lot of experience using migrations in Rails, and over time I've become just incredibly suspicious of "down migrations." I have never once been in a situation where I needed to use one, and even if I did, I'd have some reason to hesitate. Let's say everyone on my team wrote one, and they even tested the "down then up" process to ensure it applied (on their machine), unlike the normal "up" migration, that migration code was probably only executed in a single environment with test data. And even given those two ifs (1 - a down migration exists and 2 - it was tested anywhere), the darn things are still annoying and time consuming to write. I would much rather write another "up" migration in the event that I needed to roll back a change. I guess that would be "rolling forward" a change. All that said, my sphere of influence is pretty small. Has a down migration ever saved your skin? What am I not considering? |
|
That could potentially be solved in other ways, though - such as keeping separate databases for different git branches, or making database snapshots. Both of those are manual work, though - apart from the upfront effort it takes to write the "down" migration, rolling back migrations seems like the path with least friction.
Unless you don't need any of the data in your database, or it's easily reproducible (database "seeders"), in which case you can just delete the entire database and start from scratch every time.