# Migration newbie

**URL:** <https://www.ruby-forum.com/t/migration-newbie/65371>\
**Category:** Rails\
**Created:** [August 17, 2006, 8:29pm UTC](https://www.ruby-forum.com/t/migration-newbie/65371 "2006-08-17T20:29:52Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![paulbutcher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a5b964/32.png) [@paulbutcher](https://www.ruby-forum.com/u/paulbutcher)\
**Post date:** [August 17, 2006, 8:29pm UTC](https://www.ruby-forum.com/t/migration-newbie/65371/1 "2006-08-17T20:29:52Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![paulbutcher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a5b964/32.png) [@paulbutcher](https://www.ruby-forum.com/u/paulbutcher)\
**Post date:** [August 17, 2006, 8:57pm UTC](https://www.ruby-forum.com/t/migration-newbie/65371/2 "2006-08-17T20:57:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![paulbutcher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a5b964/32.png) [@paulbutcher](https://www.ruby-forum.com/u/paulbutcher)\
**Post date:** [August 17, 2006, 10:09pm UTC](https://www.ruby-forum.com/t/migration-newbie/65371/3 "2006-08-17T22:09:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![paulbutcher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a5b964/32.png) [@paulbutcher](https://www.ruby-forum.com/u/paulbutcher)\
**Post date:** [August 17, 2006, 10:12pm UTC](https://www.ruby-forum.com/t/migration-newbie/65371/4 "2006-08-17T22:12:18Z")

</div>

On 8/17/06, Pål Bergström [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> 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.

---

<div class="post-metadata">

**Author:** ![paulbutcher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/a5b964/32.png) [@paulbutcher](https://www.ruby-forum.com/u/paulbutcher)\
**Post date:** [August 17, 2006, 9:52pm UTC](https://www.ruby-forum.com/t/migration-newbie/65371/5 "2006-08-17T21:52:46Z")

</div>

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.