Repairing migrations

So occassionally my migrations go…uh… off the rails. One of them
fails, and then I start getting errors about fields already existing,
etc. Or I make some changes to a database by hand, and then need to
bring the migration back in synch with the db without nuking the db
contents.

Sometimes I can turn the schema into a migration to accomplish this.
But other times the errors continue. Is there a better way to bring a
migration and existing db into synch?

Thanks!

magic_hat wrote:

So occassionally my migrations go…uh… off the rails. One of them
fails, and then I start getting errors about fields already existing,
etc. Or I make some changes to a database by hand, and then need to
bring the migration back in synch with the db without nuking the db
contents.

Sometimes I can turn the schema into a migration to accomplish this.
But other times the errors continue. Is there a better way to bring a
migration and existing db into synch?

The biggest thing is to test your migration in the development
environment. That will get rid of many problems. But if for some reason
your migration get’s an error in the production environment you can just
comment out the part of the migration it has already done (you can tell
by where the error occured) then run again. That migration has not be
checked off yet it will just skip your commented section and pick up
where it left off.

Alternatively you can make the rest of the changes manually and then
just bump the version in the schema table to make rails think you ran
it.

Eric

On 7/19/07, Eric A. [email protected] wrote:

migration and existing db into synch?
just bump the version in the schema table to make rails think you ran it.

Eric

Or you could use a real database that supports transactional DDL.

Pat

On 19-Jul-07, at 5:09 PM, Eric A. wrote:

migration and existing db into synch?
where it left off.

Alternatively you can make the rest of the changes manually and then
just bump the version in the schema table to make rails think you
ran it.

Eric

I have, to date, found two bad habits cause havoc - if you don’t do
these two you will have more migration smiles.

  1. don’t edit by tables with your sql tool - always use migrations
    if you’re gonna use a system, us it - otherwise pain is your reward

  2. don’t edit old migrations - you’re running the the risk of
    creating a migration that’s gonna break something.
    Keep moving forward. I’ve you’ve got a new column, then create a
    migration that ads the column - don’t edit the original create migration

If you do the above (and test your migration) you won’t have to do
any column check tricks

cheers,
Jodi

An improvement is ro run your migrations in a transaction.
http://www.redhillonrails.org has a grat plugin for this (Transactional
migrations)

Regards
Wim

Jodi S. wrote:

tell

migration that ads the column - don’t edit the original create migration

If you do the above (and test your migration) you won’t have to do
any column check tricks

cheers,
Jodi


NEW on aXs GUARD: SSL VPN !! (contact your reseller for more info)


aXs GUARD has completed security and anti-virus checks on this e-mail
(http://www.axsguard.com)

Able NV: ond.nr 0457.938.087
RPR Mechelen