Rails中的Migrations(四)

Managing Tables:
    在Rails的Migrations中可以执行一些DDL的操作，例如新增，删除表等。先来看一段新增表的操作代码：

 

class CreateOrderHistories < ActiveRecord::Migration
  def self.up
    create_table :order_histories do |t|
      t.integer :order_id, :null => false
      t.text :notes
      t.timestamps
  end

   def self.down
     drop_table :order_histories
   end
end

对照create_table的方法签名很容易理解这段代码：

create_table(table_name, options = {}) {|table_definition| ...} 

 

在options的这个参数中有以下这些key-value对可以使用：

:id => 是否要生成主键；

:primary_key => 如果有主键，则作为主键的字段名。(默认为id)

:options => 其他需要在建表时指定的参数。(例如针对mysql指定数据存储引擎和字符编码)

:temporary => 建立的表为临时表

:forece => 如果创建的表已经存在，那是否要drop后再建立。(默认为false)

其中需要注意的有以下两点：

1. t.timestamps方法会给表中建立两个字段:created_at和updated_at，字段类型由相应数据库类型决定。
2. Rails默认使用的mysql数据引擎为InnoDB。如果在使用create_table方法时，使用了:options指定了额外参数，则Rails会使用数据库默认的数据存储引擎来建表。因此，如需继续使用InnoDB，则需要:options中显式声明。

Rename Table:
当系统重构时，需要修改某些table的名称时，我们可以使用Migrations提供的rename_table方法。使用的方法非常简单，请看以下的代码：

Class RenameOrderHistories < ActiveRecord::Migration
  def self.up
    rename_table :order_histories, :order_notes
  end

  def self.down
    rename_table :order_notes, :order_histories
  end
end

 rename_table方法签名的第一个参数为原表名，第二个参数为需要改成的表名。

 

Problems with rename_table:
当使用rename_table方法时，可以能在Migrations时面临一些小问题。假设我们在第四个migrations中新建了order_histories表，并填充了一些测试数据，具体代码如下：

def self.up
  create_table :order_histories do |t|
    t.integer :order, :null => false
    t.text :notes
    t.timestamps
  end

  order = Order.find :first
  OrderHistories.create(:order_id => order, :notes => "test")
end

 而在第七次的migrations中将order_histories表改名为order_notes。在过了一段时间后，你决定drop掉整个开发环境 的数据库，然后从头执行所有的migrations文件。于是在执行第四个migrations文件时，Rails会报错，因为找不到 OrderHistories这个model类了，(现在叫OrderNotes了)。
针对这个问题，Tim Lucas有个简单的处理方法。即在migration的文件中建立OrderNotes和OrderHistories两个类的"哑"类。(即没有任何功能性代码的类)这样在undo这个migration时就不会报错了。