# Migration up and down

**URL:** <https://www.ruby-forum.com/t/migration-up-and-down/65937>\
**Category:** Rails\
**Created:** [August 22, 2006, 3:18pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937 "2006-08-22T15:18:41Z")\
**Posts on this page:** 9\
**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 22, 2006, 3:18pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/1 "2006-08-22T15:18:41Z")

</div>

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

This was found at  
[http://www.rabbitcreative.com/articles/2006/03/29/ruby-on-rails-super-easy-migrations-tutorial](http://www.rabbitcreative.com/articles/2006/03/29/ruby-on-rails-super-easy-migrations-tutorial)

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

def self.down  
drop\_table :people  
end  
end"

Or this from Agile Web D. with Rails.

“The up( ) method is responsible for applying the schema changes for  
this  
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  
orders  
table.  
class AddEmailColumnToOrders \< ActiveRecord::Migration  
def self.up  
add\_column :orders, :e\_mail, :string  
end  
def self.down  
remove\_column :orders, :e\_mail  
end  
end  
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.

Btw, is there a good tutorial out there that goes through the basics in  
migration?

---

<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 22, 2006, 3:56pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/2 "2006-08-22T15:56:24Z")

</div>

That way you can create versions of your database. Your development  
server mabey has version 10 of the DB while the production server only  
has version 6.  
Next part of the scenario is that you are posting the newest version  
of the code to your production server. But wait. Something doesn’t  
work. Then you can quickly do back the command rake db:migrate  
VERSION=6 to move back the database to the point it was.

That is only one scenario of why it’s nice to have migration versions.

Each version of the database is handled by it’s own file. For example  
when you have an online store app and you are adding comments to the  
products you would add the 010\_add\_comments.rb migration file. You  
never change an active version. If your database is version 10 the  
file you should be changing is version 11. In emergency while in  
development mode you could rake it down a version and then change the  
migration file and rake it up.

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

> ```
> # t.column :name, :string
> 
> ```
> 
> "The up( ) method is responsible for applying the schema changes for  
> remove\_column :orders, :e\_mail
> 
> Btw, is there a good tutorial out there that goes through the basics in  
> migration?
> 
> –  
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).
> 
> >

## –

Jon Gretar B.  
[http://www.jongretar.net/](http://www.jongretar.net/)

---

<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 22, 2006, 4:26pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/3 "2006-08-22T16:26:11Z")

</div>

Jón Borgþórsson wrote:

> That way you can create versions of your database.

Thanks Jón. I’m getting much it better now. 🙂

So in reality you have to write our own description of what is to happen  
when you go back/down? Shouldn’t rails see that was done in the up  
method and just magically reverse that?

---

<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 22, 2006, 5:14pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/4 "2006-08-22T17:14:36Z")

</div>

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

> Thanks Jón. I’m getting much it better now. 🙂
> 
> So in reality you have to write our own description of what is to happen  
> when you go back/down? Shouldn’t rails see that was done in the up  
> method and just magically reverse that?

The problems with doing everything automagically (love that word) is  
that it simply reduces what you can do. Remember that the migration  
scripts are just plain old Ruby with some DSL. You can put pretty much  
anything inside those scripts. It’s not really uncommon to add some  
file handling into there. Such as copying files around or deleting  
some old temporary files. Anything you can do in Ruby you can do  
inside those migrations. The power of it goes way beyond databases  
even though DB work is it’s main function.

It just makes sense to allow commands for both up and down versioning.  
It’s not a lot of extra work for the programmer but it just simply  
gives him a lot of extra options.

However to save some time. If you are lucky enough to use TextMate  
then the excellent SyncPeople on Rails plugin can automagically add  
the down command while you create the up command. Or vise-versa.

## –

Jon Gretar B.  
[http://www.jongretar.net/](http://www.jongretar.net/)

---

<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 22, 2006, 9:26pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/5 "2006-08-22T21:26:29Z")

</div>

Jón Borgþórsson wrote:

> However to save some time. If you are lucky enough to use TextMate  
> then the excellent SyncPeople on Rails plugin can automagically add  
> the down command while you create the up command. Or vise-versa.

I use Eclipse with Radrails. Do you know if that plugin will work there  
as well?

---

<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 22, 2006, 6:24pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/6 "2006-08-22T18:24:09Z")

</div>

Pål Bergström wrote:

> In a migration there’s an up and down method. But how does it work,  
> really?
> 
> Btw, is there a good tutorial out there that goes through the basics in  
> migration?

PÃ¥l,

Check out my presentation slides from RailsConf. It should help you  
understand a lot.

[http://damonclinkscales.com/past/migrations-at-railsconf/](http://damonclinkscales.com/past/migrations-at-railsconf/)

-damon

---

<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 22, 2006, 9:30pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/7 "2006-08-22T21:30:11Z")

</div>

Damon C. wrote:

> Pål Bergström wrote:
> 
> > In a migration there’s an up and down method. But how does it work,  
> > really?
> > 
> > Btw, is there a good tutorial out there that goes through the basics in  
> > migration?
> 
> PÃ¥l,
> 
> Check out my presentation slides from RailsConf. It should help you  
> understand a lot.
> 
> [http://damonclinkscales.com/past/migrations-at-railsconf/](http://damonclinkscales.com/past/migrations-at-railsconf/)
> 
> -damon

I will. Thanks for the tip 🙂

(after I quick view…wow, this is good.)

---

<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 23, 2006, 7:48pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/8 "2006-08-23T19:48:11Z")

</div>

Damon,

Were you aware that tests & new migrations fail on v 1.1.6 when you  
have a default date using MySQL?

I have a default date in my development table. When I run my tests,  
they fail because schema\_dump.rb puts the default value as an  
uncommented string into the schema.rb file. I modified schema\_dumper.rb  
to use quotes when it encounters a time value in order to correct the  
problem.

This seems like a bug to me.

I also noticed that if I have a default NULL value in a table, where  
the field is numeric, the test database has a default value of 0. This  
caught me on several of my tests.

Thanks for the slides from your migration talk. I enjoyed them.

Aloha,

Mark

---

<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 25, 2006, 1:25pm UTC](https://www.ruby-forum.com/t/migration-up-and-down/65937/9 "2006-08-25T13:25:12Z")

</div>

DrMark wrote:

> Were you aware that tests & new migrations fail on v 1.1.6 when you  
> have a default date using MySQL?
> 
> I have a default date in my development table. When I run my tests,  
> they fail because schema\_dump.rb puts the default value as an  
> uncommented string into the schema.rb file. I modified schema\_dumper.rb  
> to use quotes when it encounters a time value in order to correct the  
> problem.
> 
> This seems like a bug to me.
> 
> I also noticed that if I have a default NULL value in a table, where  
> the field is numeric, the test database has a default value of 0. This  
> caught me on several of my tests.

Mark,

I was not aware of either of those.

It sounds like they could be bugs. I would submit patches with a  
failing test if you can muster them.

> Thanks for the slides from your migration talk. I enjoyed them.  
> Definitely.

-damon

> **[Damon Clinkscales](https://damonc.onuniverse.com/)**
>
> Damon Clinkscales