Rails migrations - enhanced usage


#1

Hello,
When I am writing rails migrations, quite often I make mistake in them
which
causes the migration tasks to stop halfway with error.

This causes lots of problem, because it results in half of the things in
migrations changed and other half not. Also, as the schema number is
changed,
so things cannot be rolled back.

Is there any way to make the entire migration action atomic, i.e.,
everything
or none at all?

Also, while dropping tables how can I determine whether a particular
table
exists in the database?

Thanks.


Surendra S.
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| “War is Peace! Freedom is Slavery! Ignorance is Strength!”
| – Orwell, 1984, 1948
`----


#2

Surendra S. wrote:

Also, while dropping tables how can I determine whether a particular table
exists in the database?

Thanks.

I’ve had this problem as well and like the idea of making it atomic –
or at least having an atomic option.


#3

Hi !

2006/4/3, Surendra S. removed_email_address@domain.invalid:

Hello,
When I am writing rails migrations, quite often I make mistake in them which
causes the migration tasks to stop halfway with error.

If your DB supports it, do the migration in a transaction:

def self.up
ActiveRecord::Base.connection.transaction do
create_table …
end
end

On the other hand, make your migrations as small as possible. That
way, there will be less things that you’ll have to manually rollback
if something goes wrong.

Also, a trick I often use is I dump (with data) the production DB to
development, and do the migration on the dev database. That way, I am
at least assured that the migration can run on existing data.

Last trick: dump your dev database before doing the migration. If
something breaks, you just reload the schema.

Hope that helps !


#4

Francois, thanks for that tip! I’d encountered the same thing and
wasn’t sure if transactions could be used in that way.

Jeff

François Beausoleil wrote:

Hi !

2006/4/3, Surendra S. removed_email_address@domain.invalid:

Hello,
When I am writing rails migrations, quite often I make mistake in them which
causes the migration tasks to stop halfway with error.

If your DB supports it, do the migration in a transaction:

def self.up
ActiveRecord::Base.connection.transaction do
create_table …
end
end

On the other hand, make your migrations as small as possible. That
way, there will be less things that you’ll have to manually rollback
if something goes wrong.

Also, a trick I often use is I dump (with data) the production DB to
development, and do the migration on the dev database. That way, I am
at least assured that the migration can run on existing data.

Last trick: dump your dev database before doing the migration. If
something breaks, you just reload the schema.

Hope that helps !


#5

Francois, thanks for that tip! I’d encountered the same thing and
wasn’t sure if transactions could be used in that way.

They only can for a few databases, like pgsql and mssql, that supports
transactions on schema changes. The rest of the databases will ignore
this.

So always test your migrations on a development database first and
make them small.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework


#6

“Francois B.”
removed_email_address@domain.invalid writes:

ActiveRecord::Base.connection.transaction do
at least assured that the migration can run on existing data.

Last trick: dump your dev database before doing the migration. If
something breaks, you just reload the schema.

Hope that helps !

Sure it did.

Thanks Francois and David.


Surendra S.
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| “War is Peace! Freedom is Slavery! Ignorance is Strength!”
| – Orwell, 1984, 1948
`----