I've registered your skepticism. Yes, I can't see that the benefit of satisfying my preference here outweighs the burden.
That said, I still think it's a drag to sift through multiple migration files. Thanks, Grar On Mar 19, 12:40 pm, Ar Chron <li...@ruby-forum.com> 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 rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
