Migration newbie

Rails
1

In an migration file there is one up and one down method. Below is from
Agile Web D. with Rails:

class CreateOrderHistories < ActiveRecord::Migration
def self.up
create_table :order_histories do |t|
t.column :order_id, :integer, :null => false
t.column :created_at, :timestamp
t.column :notes, :text
end
end
def self.down
drop_table :order_histories
end
end

Why is there a drop table in the same file? Will that not delete the
same table just created?

2

When the “down” method is executed, yes it will drop that table. The
“up”
and “down” methods serve different purposes, however. During a “normal”
migration, where you are adding a new featurn, only the “up” method will
be
called. The purpose of the “down” method is to undo the effects of the
the
“up” method, and is called when you are reverting to an earlier version
of
your database schema. This turns out to be incredibly handy in a
variety of
circumstances, but the first one you are likely to run into is when you
write a migration, then realize that it needs to change somehow - you
need
another column, or a not null constraint, or something. Just migrate
back
to the previous version (using “rake db:migrate VERSION=x”, where x is
the
number of the previous version), then add your changes to the “up”
method
along with corresponding undo changes in “down”, and do a standard
forward
migration.

Note that if you are working on a team with multiple people, you’ll want
to
communicate fairly closely about changing migrations, and its not a
great
idea to go back and change a migration if it has already been checked in
and
there are migrations that build upon it.

As was discussed in a thread a couple days ago, its probably also worth
wrapping your table alterations in a transaction if your database
supports
it - having a migration run halfway before hitting an error, and then
having
to cleanup the resulting structure changes, is no fun.

3

Not realy, you will see the advantage of using migrations, when you
change
your datamodel all the time.
Also when deploying to a production or test server, migrations become
very
useful.

Regards,

Harm de Laat
Kabisa ICT

4

On 8/17/06, PÃ¥l Bergström [email protected]

I can’t add a column with migration, in a simple test-db, and I suspect
it’s due to an error in my syntax. Will that then stop any further
attempts with migration? Is it this that you’re referring to?

The whole migration will abort if an error is found. AFAIK Rails creates
a
temporary structure and if migration is successful then it updates your
original database.

If you do want to start over and clean your database of any leftovers
from
bad migrations, run rake migrate VERSION=0 to start over, and then rake
migrate to get through the migrations.

5

Steve H. wrote:

As was discussed in a thread a couple days ago, its probably also worth
wrapping your table alterations in a transaction if your database
supports
it - having a migration run halfway before hitting an error, and then
having
to cleanup the resulting structure changes, is no fun.

Not sure what transaction is. Getting more and more familiare with sql,
but that is new to me. I have the latest MySQL.

I can’t add a column with migration, in a simple test-db, and I suspect
it’s due to an error in my syntax. Will that then stop any further
attempts with migration? Is it this that you’re referring to?

Trying to learn migrations, but not sure it is better for me as a lonely
developer than using MySQL’s Tools. One benefit I see is being able to
dynamically modify a db for an external user.