How to maintain migrations?

Rails
1

Hi everybody, I’m trying to figure out the best way to do migrations.
I’m
sure it’s a personal preference in some ways, but how do you prefer to
maintain migrations?
Do you create a new migration every time you think of a change, or do
you
change the existing ones, then rake db:migrate to 0 and back again?

If you do the first, you don’t have to be constantly recreating your
tables,
but your table code is all over the place. What do you all prefer?
Thanks!

2

During early development when I’m changing things drastically I’ll
update my initial migrations and rake back to 0 each time. After my
tables are all somewhat finalized, then I create a new migration for
each change.

3

On Tue, Jul 15, 2008 at 04:39:29PM -0600, Sean C. Hess wrote:

Hi everybody, I’m trying to figure out the best way to do migrations.
I’m sure it’s a personal preference in some ways, but how do you prefer
to maintain migrations?
Do you create a new migration every time you think of a change, or do you
change the existing ones, then rake db:migrate to 0 and back again?

If you do the first, you don’t have to be constantly recreating your
tables, but your table code is all over the place. What do you all
prefer? Thanks!

If you’re working alone, you can often afford to be sloppy. Better,
though,
is to be rigorous as if you were working with other people all the time.

That means a migration for every change. When you actually release
something (which usually involves tagging in subversion or whatever SCM
you
use) you can do a rake db:schema:dump to get a db/schema.rb file then
wipe
out your migrations and replace them with the contents of the schema.rb
(as
a migration with the next version number).

Of course, if any of your migrations were doing straight SQL you may
need
to do some tweaking by hand.

–Greg

4

Great, thanks for the advice guys.

On Wed, Jul 16, 2008 at 4:38 AM, [email protected] <

5

The orthodox view is that migrations should reflect every previous
state of your database structure, so if an old version of your app is
deployed somewhere you can painlessly migrate it from there. Fiddling
with old migrations is also tricky because migrating back up can fail
(e.g. if you forgot to include something you did by hand,
initializations…).

But if the old migrations were just private (not deployed anywhere)
and some of them are nothing but confusing (dead ends, mistakes) I
sometimes gloss them over, because looking at migrations can be a good
way to learn what tables and fields are at the core of the app. Very
old migrations from a stage where the app wasn’t functional yet can be
reduced to a schema.rb as Gregory said, and it’s a good thing to do.

When I realize that I want to change something that logically belongs
in a very recent migration, I migrate up, edit the migration and
migrate back to the last version. That’s relatively safe to do and
helps to keep an overview.