Migration up and down

Hi --

In a migration there's an up and down method. But how does it work,

This was found at

"class CreatePeople < ActiveRecord::Migration
def self.up
   create_table :people do |t|
     # t.column :name, :string

def self.down
   drop_table :people

Or this from Agile Web Development with Rails.

"The up( ) method is responsible for applying the schema changes for
migration while the down( ) method undoes those changes. Let’s make this
more concrete. Here’s a migration that adds an e_mail column to the
class AddEmailColumnToOrders < ActiveRecord::Migration
def self.up
add_column :orders, :e_mail, :string
def self.down
remove_column :orders, :e_mail
See how the down( ) method undoes the effect of the up( ) method."

Yes, I see !?? But...hmm...no.

For a newbie like me the above will first create the table/column and
then drop/remove it. But it doesn't. Why? How do you deal with up and
down and rake commands? Should I have a new migrate file if I want to
add a column or do I use the same? I don't get it.

The up and down methods only have an effect when they're actually
executed :slight_smile: When you do this:

   rake migrate

all new migrations have their up methods executed. "New" means:
filename indicates a level higher than the index number stored in the
database (in the special table schema_info). So if schema_info is
"3", and you have:


the up methods in 004... and 005... will be run.

At that point, if you do this:

   rake migrate VERSION=2 # migrate backwards to version 2

the down methods in 005, 004, and 003 will be run (in that order), and
the number "2" will be inserted into schema_info. You can, if you
wish, then delete, rewrite, or correct 003, 004, and 005. When you
migrate back up, it's as if they're being seen for the first time
(assuming the down methods completely reversed them).

As for writing a new migration or fixing an old one, here are the main

1. Is anyone else sharing the migrations directory? If so, you should
generally migrate forward and not edit old migrations. (And you have
to synchronize migration numbers, but that's another story....)

2. Do you have data you care about in the database? Backing out of
migrations, at least those with drop_table commands in their down
methods, will remove data from the database.

3. Are the migrations truly reversable? If not -- if the down methods
are not really able to reverse everything -- then it's best to keep
migrating forward.

4. Is the thing you're fixing due to a mistake, or is it just a design
change? If it's a mistake (like a typo in a table name), that's a
stronger argument for migrating backwards, fixing the typo, and
migrating forward. If it's a design change, just migrate forward (a
new migration), since that way you preserve a record of the whole
design process.