Migrations
Migrations are a convenient way for you to alter your database in a structured and organized manner.
1 Anatomy of a Migration
Migrations are not limited to changing the schema. You can also use them to fix bad data in the database or populate new fields:
def self.up
change_table :users do |t|
t.boolean :receive_newsletter, :default => false
end
User.update_all ["receive_newsletter = ?", true]
end
1.1 Migrations are Classes
Active Record provides methods that perform common data definition tasks in a database independent way.
- create_table
- change_table
- drop_table
- add_column
- change_column
- rename_column
- remove_column
- add_index
- remove_index
1.2 What’s in a Name
Migrations are stored in files in db/migrate , one for each migration class. The name of the file is of the form YYYYMMDDHHMMSS_create_products.rb , that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration.
以下的user store,充分说明了团队合作的问题。
For example Alice adds migrations 20080906120000 and 20080906123000 and Bob adds 20080906124500 and runs it. Alice finishes her changes and checks in her migrations and Bob pulls down the latest changes. Rails knows that it has not run Alice’s two migrations so rake db:migrate would run them (even though Bob’s migration with a later timestamp has been run), and similarly migrating down would not run their down methods.
Of course this is no substitution for communication within the team. For example, if Alice’s migration removed a table that Bob’s migration assumed to exist, then trouble would certainly strike.
1.3 Changing Migrations
You must rollback the migration (for example with rake db:rollback ), edit your migration and then run rake db:migrate to run the corrected version.
In general editing existing migrations is not a good idea: you will be creating extra work for yourself and your co-workers and cause major headaches if the existing version of the migration has already been run on production machines.
可以减少对团队的其他成员或者说项目的其它部分造成影响。
Instead you should write a new migration that performs the changes you require. Editing a freshly generated migration that has not yet been committed to source control (or more generally which has not been propagated beyond your development machine) is relatively harmless. Just use some common sense.
2 Creating a Migration
2.1 Creating a Model
The model and scaffold generators will create migrations appropriate for adding a new model. This migration will already contain instructions for creating the relevant table. If you tell Rails what columns you want then statements for adding those will also be created.
rails generate model Product name:string description:text
2.2 Creating a Standalone Migration
If you are creating migrations for other purposes (for example to add a column to an existing table) then you can use the migration generator:
rails generate migration AddPartNumberToProducts
This will create an empty but appropriately named migration:
class AddPartNumberToProducts < ActiveRecord::Migration
def self.up
end
def self.down
end
end
You are not limited to one magically generated column:
rails generate migration AddDetailsToProducts part_number:string price:decimal
这里需要强调的是,通过这种方式只能修改model,修改对应的表,而此前通过scaffold生成的view和controller是不会改变的,需要手动修改。
3 Writing a Migration
3.1 Creating a Table
Migration method create_table will be one of your workhorses.