Migration up and down

rubyonrails-talk
1

That way you can create versions of your database. Your development server mabey has version 10 of the DB while the production server only has version 6. Next part of the scenario is that you are posting the newest version of the code to your production server. But wait. Something doesn't work. Then you can quickly do back the command rake db:migrate VERSION=6 to move back the database to the point it was.

That is only one scenario of why it's nice to have migration versions.

Each version of the database is handled by it's own file. For example when you have an online store app and you are adding comments to the products you would add the 010_add_comments.rb migration file. You never change an active version. If your database is version 10 the file you should be changing is version 11. In emergency while in development mode you could rake it down a version and then change the migration file and rake it up.

2

The problems with doing everything automagically (love that word) is that it simply reduces what you can do. Remember that the migration scripts are just plain old Ruby with some DSL. You can put pretty much anything inside those scripts. It's not really uncommon to add some file handling into there. Such as copying files around or deleting some old temporary files. Anything you can do in Ruby you can do inside those migrations. The power of it goes way beyond databases even though DB work is it's main function.

It just makes sense to allow commands for both up and down versioning. It's not a lot of extra work for the programmer but it just simply gives him a lot of extra options.

However to save some time. If you are lucky enough to use TextMate then the excellent SyncPeople on Rails plugin can automagically add the down command while you create the up command. Or vise-versa.