Rails 2.2 Migration Goodies
With the imminent release of Rails 2.2, I've been spending a lot of time looking at the source code and git checkins. One area where developers will appreciate some small tweaks is migrations.
If you're not working on a multi-developer team, the default (UTC-based) numbering for migrations is a nuisance. You'll be able to change that by setting a configuration variable:
[sourcecode language='ruby']
config.active_record.timestamped_migrations = false
[/sourcecode]
That will give you the old, integer prefixes instead of the new fancy ones. Once you have those, it becomes easier to edit and re-run a specific migration, thanks to the fact that rake db:migrate:redo now takes an optional VERSION to specify the target migration to redo.
Finally, Rails 2.2 is getting transactional migrations - if you use PostgreSQL. Historically, multiple-step Rails migrations have been a source of trouble. If something went wrong during a migration, everything before the error changed the database and everything after the error wasn't applied. Also, the migration version was stored as having been executed, which means that it couldn't be simply rerun by rake db:migrate:redo after you fix the problem. Transactional migrations change this by wrapping migration steps in a DDL transaction, so that if any of them fail, the entire migration is undone.
If you're not working on a multi-developer team, the default (UTC-based) numbering for migrations is a nuisance. You'll be able to change that by setting a configuration variable:
[sourcecode language='ruby']
config.active_record.timestamped_migrations = false
[/sourcecode]
That will give you the old, integer prefixes instead of the new fancy ones. Once you have those, it becomes easier to edit and re-run a specific migration, thanks to the fact that rake db:migrate:redo now takes an optional VERSION to specify the target migration to redo.
Finally, Rails 2.2 is getting transactional migrations - if you use PostgreSQL. Historically, multiple-step Rails migrations have been a source of trouble. If something went wrong during a migration, everything before the error changed the database and everything after the error wasn't applied. Also, the migration version was stored as having been executed, which means that it couldn't be simply rerun by rake db:migrate:redo after you fix the problem. Transactional migrations change this by wrapping migration steps in a DDL transaction, so that if any of them fail, the entire migration is undone.