Rails 0.13

It looks like Rails 0.13 has been released. There’s a lot of nifty-looking stuff in there, but the one that really grabs my eye is the new migration facility. Rails now has the ability to make schema changes when you upgrade your app. So, when version 1.1 of your app comes along, and it needs to add an eye_color field to the user table, you can now handle it entirely within Rails:

class AddEyeColor < ActiveRecord::Migration
  def self.up
    add_column :users, :eye_color, :string
  end

  def self.down
    remove_column :users, :eye_color
  end
end

The nice thing is that this is completely database-independent. It’ll work on both MySQL and PostgreSQL now, and other databases as soon as their Rails drivers are updated.

One possible shortcoming with migrations: I don’t see any obvious way to enforce the correct order of migrations–if version 1.2 adds a pets table, and version 1.3 adds a nickname field to pets, then I don’t see how the upgrade process from 1.1 to 1.3 will know which order to apply the two migration scripts.

Also, the migration code seems to be a nice first start on database-independent schemas. I suspect that a near-future Rails revision will allow developers to specify the schema as a set of migrations, and then the migration mechanism will create all of the tables needed automatically. That’ll be another huge step for Rails usability.

Posted by Scott Laird Thu, 07 Jul 2005 03:28:00 GMT


Comments

  1. david about 6 hours later:

    Order is indeed very important to migrations. When using the “script/generate migration” command, all the migration files are automatically prefixed with their number in the queue. So you get 1addeyecolor.rb, 2addpets.rb. And rake migrate knows in which order to apply (and keeps a tally on what has been applied in the schemainfo table).

  2. Scott Laird about 10 hours later:

    Ahh, good. That seemed like an important thing to be missing :-).