Migrations: Did they mature with Rails 2.1.#

With the new face of Rails (Rails 2.1 and beyond), came the change in the way migrations used to work.
So lets see some of the changes that went into migrations (that is when Rails was 1.2.3)… the then and now changes …

First of all, serial numbers for migrations are gone and they have made way for the UTC based names for
the migrations. So earlier (pre Rails 2.1 era) if one created migration scripts, they used to get their
names serially like…


whereas now the names have the UTC timestamps on them …


With this new change rake db:migrate could apply all migrations that had not yet gone into database (as now
all migrations run and add an entry into the database migration table). Because of this the issue with the earlier version of migrations was taken care of i.e old migrations heavily used to rely on once single entry to run the migrations. If you somehow happened to screw the version number, u ended up getting failed migration errors.

Along came one more functionality which now lets run the up and down functions for a particular migration.

$ rake db:migrate:up VERSION=20080601000002
$ rake db:migrate:down VERSION=20080601000002

rake db:migrate:up or rake db:migrate:down let you go up or roll back a particular migration’s changes.

The other change was the name of the table that stored the migration information. In earlier version of
rails, it used to be ‘schema_info’ which gave way to ‘schema_migrations’. So I would suggest not to look
for the earlier name in case you got your application migrated from Rails 1.2.# to Rails 2.1.#.

We also got rid of specifying

t.column <attribute_name> <data_type>

for the attributes and it got reduced to

t.<data_type> <attribute_name>

which would look something like this in the new migration…

class CreateBooks < ActiveRecord::Migration
def self.up
create_table :books do |t|
t.integer :code, :null => false
t.string :name
t.string :author_id ... for the author's sake...

def self.down
reverse the gears ...

To add to this, timestamps came into existence which was a required addition so that we could save
some keystrokes and bid goodbye to

t.column created_at
t.column updated_at

So those were some of the changes cum additions ….
To go ahead with, lets see the cycle of migration …

Now with the new mmigrations, when they are run, this is what happens …

1. Table ‘schema_migrations’ is created if that does not exist.
2. For every migrations that runs successfully, an entry is created in the schema migrations table.
3. The leading part of the migration filename gets stored into the table.
For eg. 20080601000001 gets saved when 20080601000001_create_books.rb runs and updates the database.
4. New migrations run when an entry is not found in the migrations table.

So now if you want to force and roll your database to a specific version, you supply the VERSION= parameter

$ rake db:migrate VERSION=20080601000002

If that version happens to be greater than those already in, the migrations will be applied. But in case the
version number is lesser than those in the migrations table, than Rails undoes the changes and self.down comes into play and thus migrations run in reverse direction to undo changes to the version that was specified.

One good thing which most of us must be missing and which is gone with arrival of the new migrations is the shorter version numbers for the migration files.

Earlier we could do something like

$ rake db:migrate VERSION=2

which has become this now

$ rake db:migrate VERSION=20080601000002

So I bet it is not so easy to remember the exact 14 character version number but I guess as long as we have Ctrl C n Ctrl V, it wont be much of a problem 😉

So to end or startup with, I think they did mature just like other things that matured with time …
Rails included 🙂

Time for me to migrate to a new blog post .. till then keep migrating the new way …

4 thoughts on “Migrations: Did they mature with Rails 2.1.#

  1. Good summary of the changes to how migrations work over the past few years. Also don’t forget we now have change_table which is handy for making lots of modifications to the same table. Also I think belongs_to is fairly recent (or at least I discovered it fairly recently).

  2. I think its looking better. I noticed you changed your blog around. And you have some more Migrations discussed. You really like migrating 🙂

    Whats your take on migrating say an Access DB to MySQL? Any thoughts?

  3. Pretty good! I see you made changes to yours. 🙂

    Hey Gaurav what are your thoughts on migrating say an Access DB to MySQL?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s