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