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…


001_create_books.rb
002_create_shelves.rb

whereas now the names have the UTC timestamps on them …

20080601000001_create_books.rb
20080601000002_create_shelves.rb

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...
      t.timestamps
    end
  end

  def self.down
    reverse the gears ...
  end
end


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 …

Migrations

I am back on track .. track of writing something new here…
and this time it is Migrations .. Rails Migrations ..

As you must be knowing (u all Rails enthusiasts) that migrations allow
you to make changes to your database schema. In doing so, you also get the
facility of moving from version x to y of your database.

So this time I was required to add a column to my already existing model.
So I went ahead and did something like this …

def self.up
  add_column :media, :category_name, :string
  muvee = Media.find_by_name('whoami')
  muvee.update_attributes :category_name => 'action'
end

When I ran this migration, the new column got added to the table but the
migration did not update the data in the table.

I reran.. thinking I missed something but nothing happened.

After a while I came across something and added it to the migration code. This time

it did add the column along with the data.

def self.up
  add_column :media, :category_name, :string
  muvee = Media.find_by_name('whoami')
  FileType.reset_column_information # This was added ...
  muvee.update_attributes :category_name => 'action'
end

What ‘FileType.reset_column_information’ does is that it makes the new schema change
available to the model as it resets the column information ( w/ the information about the new column). Thus the changes become available for the new data to be inserted properly.

Hope this information helps someone out there in case such situation arises.

Cheers !!!