More Flexible Rails Migrations

October 22nd, 2007 Author: Christopher Bottaro

Before we moved from our own internally developed PHP framework to using Ruby on Rails, I had written a database migration library that mimics Rail’s with two key differences:

1. It allowed for retroactive running of migrations with versions at or below the current database version.
2. It allowed a developer to force run a migration, even if that migration had already been run before.

Point one solves the problem where you have multiple developers sharing the same development database and all writing migrations at the same time. For instance, you create a migration 002_blah, but before you run it and check it in, another developer created, ran and checked in migration 002_bleck. By default in Rail’s, your 002_blah migration will never be run because the database is already on version 002. My library instead says “ok, I’m on version 002, but lets see if there any new migrations at or below that version that have not been run yet.”

Point two is dangerous and indeed has lead our database to get all mucked up more than a few times, but hey, it’s a feature no one is forcing you to use. The “force run” feature lets you run a migration (either up or down) even if it has already been run before. This feature is nice for when you realize you made a mistake in an already run migration and instead of making a new migration, you just want to edit and fix the existing one. You “force down” it, edit/fix it, then “force up” it.

I made a plugin for Rails called Retroactive Migrations (r_migrations) that implements this behavior. For installation and documentation, please see my personal blog post about it.

Entry Filed under: Backend, General, Rails