Shantanu P. wrote:
But then what is the purpose of db:migrate:down (and self.down method in
On a deployed database, the only direction should be up. If you deploy a
version, and encounter an emergency, the cap rollback feature cannot
database back. If the current code no longer likes the database, you
use db:migrate:down, iff it is fully tested, and it won’t erase any live
However, once you deploy, if you rethink a feature, and want less
fields, you should write a progressive migration that removes those
its .up method. Its .down method, if any, should put the fields back in.
Because you should not write proactive code into a .down method without
immediately testing it, you generally should not write anything in a
method when you create a new migration. Do not, for example, write a
method because you think you must (or because an Official Style
you to) and then not test it. A colleague might run it, thinking it’s
and get a nasty surprise. Worse, that could be you!
The major benefit of the .down method derives from a problem with unit
their fixtures. Unit tests should cover every line of your Rails project
/except/ the lines in your historical migrations! At migration time,
might dislike the new version. You can build a .down method, then fix
while alternately calling down and up on the migration.