In an migration file there is one up and one down method. Below is from Agile Web Development 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? -- Posted via http://www.ruby-forum.com/.
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. On 8/17/06, P?l Bergstr?m <pal@palbergstrom.com> wrote:> > In an migration file there is one up and one down method. Below is from > Agile Web Development 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? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/430638e7/attachment.html
Steve Holder 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. -- Posted via http://www.ruby-forum.com/.
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 On 8/17/06, P?l Bergstr?m <pal@palbergstrom.com> wrote:> > Steve Holder 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. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/0b59e14b/attachment.html
On 8/17/06, P?l Bergstr?m <pal@palbergstrom.com>> 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. -- "Impossible is nothing." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/bed26c5e/attachment.html