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
"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?
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 [email protected] 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/.
–
Jon Gretar B.
http://www.jongretar.net/
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?
On 8/22/06, Pål Bergström [email protected] 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/
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?
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/
-damon
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/
-damon
I will. Thanks for the tip
(after I quick view…wow, this is good.)
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
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