rubyonrailsin

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 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.