aboutsummaryrefslogblamecommitdiffstats
path: root/railties/doc/guides/source/migrations/using_models_in_migrations.txt
blob: 35a4c6fdfdffb99340fb51aa172edc84bbbb44d1 (plain) (tree)
1
2
3
4
5
6
7
          
                                     


                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      
 
                                                                                                                                                                                                                                        















                                                       
                                                                                                                                   


                                    
                                                                                                                                                                                                                                                                                                                                                             

















                                                       
[[models]]
== Using Models In Your Migrations ==
When creating or updating data in a migration it is often tempting to use one of your models. After all they exist to provide easy access to the underlying data. This can be done but some caution should be observed. 

Consider for example a migration that uses the Product model to update a row in the corresponding table. Alice later updates the Product model, adding a new column and a validation on it. Bob comes back from holiday, updates the source and runs outstanding migrations with `rake db:migrate`, including the one that used the Product model. When the migration runs the source is up to date and so the Product model has the validation added by Alice. The database however is still old and so does not have that column and an error ensues because that validation is on a column that does not yet exist.

Frequently I just want to update rows in the database without writing out the SQL by hand: I'm not using anything specific to the model. One pattern for this is to define a copy of the model inside the migration itself, for example:

[source, ruby]
-------------------------
class AddPartNumberToProducts < ActiveRecord::Migration
  class Product < ActiveRecord::Base
  end
  
  def self.up
    ...
  end

  def self.down
    ...
  end
end
-------------------------
The migration has its own minimal copy of the Product model and no longer cares about the Product model defined in the application.

=== Dealing with changing models ===

For performance reasons information about the columns a model has is cached. For example if you add a column to a table and then try and use the corresponding model to insert a new row it may try and use the old column information. You can force Active Record to re-read the column information with the `reset_column_information` method, for example

[source, ruby]
-------------------------
class AddPartNumberToProducts < ActiveRecord::Migration
  class Product < ActiveRecord::Base
  end
  
  def self.up
    add_column :product, :part_number, :string
    Product.reset_column_information
    ...
  end

  def self.down
    ...
  end
end
-------------------------