Shantanu Pavgi wrote: > But then what is the purpose of db:migrate:down (and self.down method in > migration file)?
On a deployed database, the only direction should be up. If you deploy a new version, and encounter an emergency, the cap rollback feature cannot roll your database back. If the current code no longer likes the database, you could then use db:migrate:down, iff it is fully tested, and it won't erase any live data. However, once you deploy, if you rethink a feature, and want less database fields, you should write a progressive migration that removes those fields in 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 .down method when you create a new migration. Do not, for example, write a .down method because you think you must (or because an Official Style Guideline told you to) and then not test it. A colleague might run it, thinking it's tested, and get a nasty surprise. Worse, that could be you! The major benefit of the .down method derives from a problem with unit tests and their fixtures. Unit tests should cover every line of your Rails project - /except/ the lines in your historical migrations! At migration time, your tests might dislike the new version. You can build a .down method, then fix the tests while alternately calling down and up on the migration. -- Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
