OK. Also, I was just thinking: if I create models and then, without a migration, create corresponding tables, I have sidestepped the problem, such as it is.
Anyway, I've registered your skepticism. Thanks, Grar On Mar 19, 12:40 pm, Ar Chron <[email protected]> wrote: > 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 viahttp://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.
