Misuse

I’ve been learning about migrations in Rails. It’s basically a deployment system that is pretty well thought out. Some people say it’s not useful for production deployment but other credible people say they use it for production all the time - just be sure to test the deployment just like any other part of the application.
(This makes me think of a future article that would describe a testing harness for migration files - a little tricky since migrations run major Data Definition Langauge (DDL) changes and are executed “out of band” of the rest of Rails.

The idea is that you have a sequence number (version) attached to your database (separate table). You have a bunch files in a migration folder that are integrated into the rails framework (so when they run you have access to existing model code and other objects). The basic idea is that each sequence file (files start with a number which is the same as the sequence number stored in the “schema_info” table in your working database). So I’ve got 001_AppEmpty.rb (empty file), 002_Create_tables.rb, 003_Seed_metadata.rb To create a new migration file simply enter the following code from the root of your Rails application folder:

./script/generate migration [MigrationName]

Note that you don’t put a three digit number in yourself, the migration script automatically does that for you. Each file has a Migration object with two methods: “up” and “down” - for up, you put code that is required to move to the next revision. For down, you put code that would undo “up” (if possible). This allows you to create and modify tables while you’re working on model code and then issue statements that basically say “upgrade database to version 003″ - which will run the “up” method from whatever version your database is in (say 001) to the version you want to be (003). Code to move to version three (from within your rails application root):

rake db:migrate version=003

It allows you to version control schema changes as if they were (truly) code changes. Rails provides a non-SQL DDL language to let you abstract some of this from the connectors. (Example of some basic DDL create tables stuff is below). A final tip: be sure to make a starting file with nothing in it. I used the migration file name “AppEmpty” which resulted in a migration file “001AppEmpty.rb” This allows you to specify “version=001″ and rollback to this empty file (and therefore an empty database, if you built your “down” methods correctly). It’s handy for testing when your first migration file holds a lot of data defintions that you want to redo frequently. Anyway, I thought others might find this very basic discussion useful. Sample DDL code in Rails migration version files: (Note “limit” keyword is really about “size” of underlying column in this context).

    #data tables
    create_table :table1 do |t|
      # meta data
      t.column :id :primary_fkey, :limit => 20, :null => false
      t.column :fkey2 :integer, :limit => 20, :null => false
      t.column :fkey3 :integer, :limit => 20
      # data
      t.column :field4 :string
    end

    create_table :table2 do |t|
      # meta data
      t.column :id :primary_fkey, :limit => 20, :null => false
      t.column :fkey2 :integer, :limit => 10, :null => false
      t.column :fkey3 :integer, :limit => 20, :null => false
      # data
      t.column :field4 :string, :limit=>255
      t.column :field5 :string, :limit=>127
      t.column :field6 :text
      t.column :field7 :text
      t.column :field8 :text
      t.column :field9 :decimal, :precision => 8, :scale => 2
    end