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 Development 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?
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---
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 <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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 Development 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? > > -- > Posted via http://www.ruby-forum.com/. > > > >-- -------------- Jon Gretar Borgthorsson http://www.jongretar.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
2006-Aug-22 13:39 UTC
[Rails] Re: Migration up and down
Hi -- On Tue, 22 Aug 2006, Pl Bergstrm wrote:> > 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 Development with Rails. > > "The up( ) method is responsible for applying the schema changes for > this > migration while the down( ) method undoes those changes. Lets make this > more concrete. Heres 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.The up and down methods only have an effect when they''re actually executed :-) 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: 001_create_somethings.rb 002_do_something_else.rb 003_create_others.rb 004_correct_some_mistake.rb 005_yet_another_migration.rb 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 considerations: 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. David -- http://www.rubypowerandlight.com => Ruby/Rails training & consultancy ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <----- http://dablog.rubypal.com => D[avid ]A[. ]B[lack''s][ Web]log http://www.manning.com/black => book, Ruby for Rails http://www.rubycentral.org => Ruby Central, Inc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 8/22/06, Pål Bergström <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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 Borgthorsson http://www.jongretar.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Damon Clinkscales 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/ > > -damonI will. Thanks for the tip :-) (after I quick view...wow, this is good.) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 http://damonclinkscales.com/ -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---