Grary wrote: > Hi, > > I prefer to keep one migration per model, but lately I'm adding data > that's expensive to drop every time I change my models.
So don't do that. You've chosen to fight a (very) hard battle if that's the manner in which you are trying to use migrations. Down the road, when you want to add a column to a table that has 100,000 rows of data, you're going through a backup and restore for that table just so you can have a single migration file per table??? If it really is just a preference, as opposed to a hard-driven requirement, then embrace the multiple migrations convention. > > How do I db:drop and db:migrate only selected tables/files? Basically, > I want to ignore certain tables and migrations altogether during > certain development phases. > The weasely approach would be to leave all the migration files in place, and edit the contents of the migration files before you do any migrations, up or down. If you don't want to perform a step, comment out all the business logic inside that migration file, leaving just a self.up (or self.down) that does nothing. Sounds like a royal PITA to me. -- Posted via http://www.ruby-forum.com/. -- 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 [email protected]. 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.
