I really like the migrations that Rails offers. However, I am
wondering if I am missing an easier way to manage them. I have tried
both of the methods suggested in AWDWR…
I have employed the method of keeping all changes to a specific model
in a single migration file, but end up constantly rolling back the
version and then reloading every time I want to make changes to that
specific table.
To me it seems that migrations should never be rolled back for any
reason. I guess it’s nice to have the “down” method, but I don’t see
a lot of use for it unless you only want to step back from the most
recent migration. Stepping back more than one version removes changes
that I almost always still want to keep.
So that leads me to the method of adding migration after migration
without regard for organizing the models. However, that soon becomes
a bit of a mess.
I think I’m looking for the best of both worlds. Would it not be
easier and more natural for the migrations for each model to be
separated into folders, much like the folder structure of the views?
Within each folder the numbering would start from 000 and the overall
schema and schema table would track the schema version per model. I’m
sure that this would cause another host of problems. Or can this
already be done and I’m missing it?
Best Regards,
David Baldwin
On Apr 4, 2007, at 11:52 PM, David Baldwin wrote:
reason. I guess it’s nice to have the “down” method, but I don’t see
separated into folders, much like the folder structure of the views?
Within each folder the numbering would start from 000 and the overall
schema and schema table would track the schema version per model. I’m
sure that this would cause another host of problems. Or can this
already be done and I’m missing it?
Best Regards,
David Baldwin
First, let me point out the big (biggest?) problem with your idea:
How do you keep the migrations for two models in sync when you add a
new relation? Say when you add a Pet model to your Person with
has_many :pets and a Pet belongs_to :person. You’d have a pets/
000_create migration and a people/027_add_pets migration and then how
would you know to roll back a version?
I tend to work with a single migration and may roll it backward and
forward a few times (with some manual cleanup 
as I’m working out
something new. However, once it is checked in it doesn’t change. If
I have to add another field the next day, a new migration is the way
to go. There have been about a dozen times that I’ve considered
writing a task to allow “rake db:migrate:down” or “rake db:migrate
VERSION=-1”, but so far it hasn’t caused enough pain to be more than
a ‘thought’.
-Rob
Rob B. http://agileconsultingllc.com
[email protected]
I’m not sure I completely understand, but think that it is likely that
I don’t have enough experience with all of the issues that could
arise. I should mention that I, up to this point, have not typed any
relationship DDL statements into the migrations. I rely solely on the
ruby model relationship to manage foreign keys even though I have
heard this is a no-no.
At any rate, I am saying that with this method there would never, ever
be a rollback…only revisions that overwrite the old. The folder
structure would simply keep things more organized.
Also, this really hasn’t caused me much pain either. I’m just trying
to consider how things would work in a team environment in the future.
Best Regards,
David Baldwin