During this development project, I’ve evolved from “Total Rails Noob” to
“Rails Tyro, Class IV”. (And I thank everyone on this list who has
helped me along!)
I’ve also accrued 67 migrations as I’ve thrashed around and created
tables, deleted tables, added columns, dropped columns, renamed columns,
added indices to tables… you name it.
But I now have a reasonably stable set of models and tables.
Wouldn’t it make sense to “snapshot” the configuration and flush all the
migrations? It seems I could replace all the existing migrations with
the contents of schema.rb. And my guess is that it would speed up
launch time (which is become an issue for me…)
Good idea? Bad idea? Do people do this? If so, is there some rake
task to simplify the process?
TIA.
Fearless F. wrote:
Wouldn’t it make sense to “snapshot” the configuration and flush all the
migrations? It seems I could replace all the existing migrations with
the contents of schema.rb. And my guess is that it would speed up
launch time (which is become an issue for me…)
How would that speed up launch time? I could certainly see that it would
speed up the initial migration when deploying for the first time and
running your migrations on the production database, but that probably
isn’t a huge deal.
I could be wrong, but I don’t see the issue.
Fearless F. wrote:
During this development project, I’ve evolved from “Total Rails Noob” to
“Rails Tyro, Class IV”. (And I thank everyone on this list who has
helped me along!)
I’ve also accrued 67 migrations as I’ve thrashed around and created
tables, deleted tables, added columns, dropped columns, renamed columns,
added indices to tables… you name it.
Yes, that’s what happens.
But I now have a reasonably stable set of models and tables.
Wouldn’t it make sense to “snapshot”
That is what db/schema.rb does. You should have that file in version
control.
the configuration and flush all the
migrations? It seems I could replace all the existing migrations with
the contents of schema.rb.
No, keep the migrations. (Some people advocate consolidating old
migrations, but I’ve never done this.)
And my guess is that it would speed up
launch time (which is become an issue for me…)
Then you guess wrong. Migrations have nothing at all to do with startup
time.
Good idea? Bad idea? Do people do this? If so, is there some rake
task to simplify the process?
TIA.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Your migrations are really just a set of steps to a specific point. I
have seen and done ‘migration maintenance’ multiple ways.
On one team, there is a certain ‘sanctity’ to the notions of migrations,
and they are all kept separate and unaltered. Blew it in your last
migration? Well, make a new one and fix it. All the ugly history is
there.
On another, at each general delivery release, migrations are accompanied
with a ‘compaction’ of migrations for that release into a unified single
step. As one person said, “No need to keep the dirty laundry laying
about.”
Either way works, just depends on the situation. And as Marnen
mentioned, version control is your friend no matter which method you
choose.
@Robert W.:
How would that speed up launch time?
…
I could be wrong, but I don’t see the issue.
Meh. You are right. Chalk this brain bubble up to a solid week of 18
hour coding sessions. My error.
@Marnen Laibow-Koser
You should have that [db/schema.rb] in version control.
But of course! ‘fool’ != ‘stupid’ 