rubyonrailsin

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-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.