For an alternative see my article at http://pivots.pivotallabs.com/users/alex/blog/articles/305-collapsing-migrations
If you make it part of your process to regularly collapse migrations (like after every deploy), you avoid both of the problems mentioned above (referencing old class definitions and taking a long time) but you also avoid the problems with relying on schema.rb, namely : * your development and test environments will be using the same technique (migrations) for creating/altering the DB * your migrations will be exercised by developers and test builds before being deployed * you won't get burned by forgetting to export and check in schema.rb after adding a migration Anyway, I'm not trying to change anyone's mind here, but this technique has worked really well for us on several projects. Cheers - - Alex --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@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-core?hl=en -~----------~----~----~----~------~----~------~--~---
