Active Record - 数据库迁移(Migration)
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook
Migrations(数据库迁移)可以让你用 Ruby 程式来修改数据库结构。相较于直接进数据库系统使用 SQL 修改结构(例如使用 phpMyAdmin 工具来修改),使用 Migrations 可以让我们有记录地进行数据库修改,每次变更就是一笔 Migration 记录。在没有 Migration 之前,如果你手动修改了数据库,那么你就必须通知其他开发者也进行一样的修改步骤。另外,在正式布署的服务器上,你也必须追踪并执行同样的变更才行。而这些步骤如果没有记录下来,就很容易出错。
Migrations 会自动追踪哪些变更已经执行过了、那些还没有,你只要新增 Migration 档案,然后执行 rake db:migrate 就搞定了。它会自己搞清楚该跑哪些 migrations,如此所有的开发者和正式布署的服务器上,就可以轻易的同步最新的数据库结构。另外一个优点是: Migration 是独立于数据库系统的,所以你不需要烦恼各种数据库系统的语法差异,像是不同型态之类的。当然,如果要针对某个特定数据库系统撰写专属功能的话,还是可以透过直接写 SQL 的方式。
新增 Migration 档案
执行以下指令,就会在 db/migrate/ 目录下产生如 20110203070100_migration_name.rb 的档案
rails g migration migration_name
注意到在 migration_name.rb 前面有着如 YYYYMMDDHHMMSS 的时序前置,用来表明执行的顺序。在早先的 Rails 版本中,是使用编号 1,2,3 来指名执行的顺序,但是如果有不同分支多人开发就可能会有重复的编号,因此在 Rails 2.1 之后的版本改采用时间戳章,让 Rails 能够应付多人开发的状况。
migration_name 常见的命名方式有
Add字段名To表格名
或是Remove字段名From表格名
,不过这没有一定,能描述目的即可。
让我们打开这个档案看看:
class MigrationName < ActiveRecord::Migration[5.1]
def change
end
end
在这个类别中,包含了一个方法是change,这会在执行这个 migration 时执行。
Migration 可用的方法
在上述change方法里,我们有以下方法可以使用:
对资料表做修改:
- create_table(name, options) 新增资料表
- drop_table(name) 移除资料表
- rename_table(old_name, new_name) 修改资料表名称
- change_table 修改资料表字段
个别修改资料表字段:
- add_column(table, column, type, options) 新增一个字段
- rename_column(table, old_column_name, new_column_name) 修改字段名称
- change_column(table, column, type, options) 修改字段的型态(type)
- remove_column(table , column) 移除字段
新增、移除索引:
- add_index(table, columns, options) 新增索引
- remove_index(table, index) 移除索引
options 可为空,或是:unique => true
表示这是唯一。
新增、移除外部键限制:
- add_foreign_key(from_table, to_table, options)
- remove_foreign_key(from_table, to_table, options)
options 可为空,或是可自定:column => from_table_foreign_key_column
(默认是{to_table}_id
)和:primary_key => to_table_primary_key_column
(默认是id
)。
新增和移除 Table
执行 rails g model 时,Rails就会顺便新增对应的 Migration 档案。以上一章产生的categories migration为例:
class CreateCategories < ActiveRecord::Migration[5.1]
def change
create_table :categories do |t|
t.string :name
t.integer :position
t.timestamps
end
add_column :events, :category_id, :integer
add_index :events, :category_id
end
end
其中的 timestamps 会建立叫做 created_at 和 updated_at 的时间字段,这是Rails的常用惯例。它会自动设成资料新增的时间以及会后更新时间。
修改 Table
我们来试着新增一个字段吧:
rails g migration add_description_to_categories
打开 db/migrate/20110411163049_add_description_to_categories.rb
class AddDescriptionToCategories < ActiveRecord::Migration[5.1]
def change
add_column :categories, :description, :text
end
end
完成后,执行bin/rake db:migrate
便会实际在数据库新增这个字段。
数据库的字段定义
为了能够让不同数据库通用,以下是Migration中的资料型态与实际数据库使用的型态对照:
Rails中的型态 | 说明 | MySQL | Postgres | SQLite3 |
---|---|---|---|---|
:string | 有限长度字串 | varchar(255) | character varying(255) | varchar(255) |
:text | 不限长度文字 | text | text | text |
:integer | 整数 | int(4) | integer | integer |
:float | 浮点数 | float | float | float |
:decimal | 十进制数 | decimal | decimal | decimal |
:datetime | 日期时间 | datetime | timestamp | datetime |
:timestamp | 时间戳章 | datetime | timestamp | datetime |
:time | 时间 | time | time | datetime |
:date | 日期 | date | date | date |
:binary | 二进制 | blob | bytea | blob |
:boolean | 布林值 | tinyint | boolean | boolean |
:references | 用来参照到其他Table的外部键 | int(4) | integer | integer |
另外,字段也还有一些参数可以设定:
:null
是否允许NULL,默认是允许,即true
:default
默认值:limit
用于string、text、integer、binary指定最大值:index => true
直接加上索引:index => { :unique => true }
加上唯一索引:foreign_key => true
加上外部键限制
例如:
create_table :events do |t|
t.string :name, :null => false, :limit => 60, :default => "N/A"
t.references :category # 等同于 t.integer :category_id
end
参考资料:ActiveRecord::ConnectionAdapters::TableDefinition
字段名称惯例
我们已经介绍过了 timestamps 方法会自动新增两个时间字段,Rails 还保留了几个名称作为惯例之用:
字段名称 | 用途 |
---|---|
id | 默认的主键字段名称 |
{tablename}_id | 默认的外部键字段名称 |
created_at | 如果有这个字段,Rails便会在新增时设定时间 |
updated_at | 如果有这个字段,Rails便会在修改时设定时间 |
created_on | 如果有这个字段,Rails便会在新增时设定时间 |
updated_on | 如果有这个字段,Rails便会在修改时设定时间 |
{tablename}_count | 如果有使用 Counter Cache 功能,这是默认的字段名称 |
type | 如果有这个字段,Rails便会启动STI功能(详见ActiveRecord章节) |
lock_version | 如果有这个字段,Rails便会启动Optimistic Locking功能(详见ActiveRecord章节) |
Migration 搭配的 Rake 任务
- rake db:create 依照目前的 RAILS_ENV 环境建立数据库
- rake db:create:all 建立所有环境的数据库
- rake db:drop 依照目前的 RAILS_ENV 环境删除数据库
- rake db:drop:all 删除所有环境的数据库
- rake db:migrate 执行Migration动作
- rake db:rollback STEP=n 回复上N个 Migration 动作
- rake db:migrate:up VERSION=20080906120000 执行特定版本的Migration
- rake db:migrate:down VERSION=20080906120000 回复特定版本的Migration
- rake db:seed 执行 db/seeds.rb 加载种子资料
- rake db:version 目前数据库的Migration版本
- rake db:migrate:status 显示目前 migrations 执行的情况
如果需要指定Rails环境,例如production,可以输入 RAILS_ENV=production rake db:migrate
种子资料 Seed
种子资料Seed的意思是,有一些资料是应用程式跑起来必要基本资料,而这些资料的产生我们会放在db/seeds.rb这个档案。例如,让我们打开来,加入一些基本的Category资料:
# This file should contain all the record creation needed to seed the database with its default values.
# The data can then be loaded with the rake db:seed (or created alongside the db with db:setup).
#
# Examples:
#
# cities = City.create([{ name: 'Chicago' }, { name: 'Copenhagen' }])
# Mayor.create(name: 'Emanuel', city: cities.first)
Category.create!( :name => "Science" )
Category.create!( :name => "Art" )
Category.create!( :name => "Education" )
输入rake db:seed
就会执行这个档案了。通常执行的时机是第一次建立好数据库和跑完Migration之后。
资料 Migration
Migrations 不只可以用来变更资料表定义,它也很常用来迁移资料。新增或修改字段时,还蛮常也需要根据现有的资料,来设定新字段的值。这时候我们就会在 Migration 利用 ActiveRecord 来操作资料。
不过,如果你在Migration中修改了资料表字段,随即又使用这个Model来做资料更新,那么因为Rails会快取资料表的字段定义,所以会无法读到刚刚修改的资料表。这时候有几个办法可以处理:
第一是呼叫 reset_column_information 重新读取资料表定义。
第二是在 Migration 中用 ActiveReocrd::Base 定义一个新的空白 Model 来暂时使用。
第三是用 execute 功能来执行任意的 SQL。
Production上跑Migration注意事项
当有上万笔资料的时候,如果有修改数据库表格ALTER TABLE
的话,他会Lock table无法写入,可能会跑好几个小时很难事前预估。建议用staging server用接近production的资料来先测试会跑多久。
- http://www.engineyard.com/blog/2011/making-migrations-faster-and-safer/
- http://backstage.soundcloud.com/2011/05/introducing-the-large-hadron-migrator-3/
bulk参数
:bulk => true
可以让变更数据库字段的Migration更有效率的执行,如果没有加这个参数,或是直接使用addcolumn
、rename_column
、remove_column
等方法,那么_Rails会拆开SQL来执行,例如:
change_table(:users) do |t|
t.string :company_name
t.change :birthdate, :datetime
end
会产生:
ALTER TABLE `users` ADD `im_handle` varchar(255)
ALTER TABLE `users` ADD `company_id` int(11)
ALTER TABLE `users` CHANGE `updated_at` `updated_at` datetime DEFAULT NULL
加上:bulk => true
之后:
change_table(:users, :bulk => true) do |t|
t.string :company_name
t.change :birthdate, :datetime
end
会合并产生一行SQL:
ALTER TABLE `users` ADD COLUMN `im_handle` varchar(255), ADD COLUMN `company_id` int(11), CHANGE `updated_at` `updated_at` datetime DEFAULT NULL
这对已有不少资料量的数据库来说,会有不少执行速度上的差异,可以减少数据库因为修改被Lock锁定的时间。
Schema档案的格式
db/schema.rb这个档案是根据Migrations迁移最后的结果,自动产生出来的终极数据库纲要档案。这样如果要全新建立一个数据库,就不需要用Migrations一个一个从头跑到尾(一个年久的Rails专案也非常有可能没办法顺利跑完),可以用bundle exex rake db:schema:load
这个指令直接加载纲要进空的数据库。
另外,每次跑自动化测试的时候,为了节省建立数据库的时间,也会使用这个Schema纲要。这个纲要默认的格式是:ruby
,也因此没办法表达出特定数据库所专属的功能,像是触发(triggers)或是预存程序(stored procedures)等等。所以如果你的 Migration 中有自定的 SQL 陈述句,需要把schema的格式设定成:sql
。请修改config/application.rb加上
# Use SQL instead of Active Record's schema dumper when creating the database.
# This is necessary if your schema can't be completely dumped by the schema dumper,
# like if you have constraints or database-specific column types
# config.active_record.schema_format = :sql
改用 :sql 的话,Rails 会倒出现有的 development 数据库,产生 #{Rails.env}_structure.sql 档案来作为测试数据库之用。