我平时一直是用 reversible 做 migration 的，效果很好

class SplitNameMigration < ActiveRecord::Migration
  def change
    add_column :users, :first_name, :string
    add_column :users, :last_name, :string

    reversible do |dir|
      User.reset_column_information
      User.all.each do |u|
        dir.up   { u.first_name, u.last_name = u.full_name.split(' ') }
        dir.down { u.full_name = "#{u.first_name} #{u.last_name}" }
        u.save
      end
    end

    revert { add_column :users, :full_name, :string }
  end
end

#1 楼 @ibachue 虽然没用过，但看了一下文档，应该和这个帖子讨论的不是同一个问题...

reversible 解决的问题是 reversible schema migration 的写法问题，如果没有 reversible，你的这段代码应该等价于：

class SplitNameMigration < ActiveRecord::Migration
  def up
    add_column :users, :first_name, :string
    add_column :users, :last_name, :string

      User.reset_column_information
      User.all.each do |u|
        u.first_name, u.last_name = u.full_name.split(' ') 
        u.save
      end
   revert { add_column :users, :full_name, :string }
  end

  def down
    revert {add_column :users, :first_name, :string}
    revert {add_column :users, :last_name, :string}
     User.all.each do |u|
        u.full_name = "#{u.first_name} #{u.last_name}" 
        u.save
      end
    add_column :users, :full_name, :string 
  end
end

其实这是一个很好的反例...本质上还是开头提到的Bad Schema Migration。因为你用了 change 这个 api，data migration 和 schema migration 混合的时候就必须引入 reversible 机制。但如果深究这种混合写法的问题呢，还可以发现，如果 User 表大一些呢，这时候 schema migration 就会卡住，后面的 schema migration 一直在等待。这时候 schema 迁移了一半，然后在中间在跑一个耗时的 task，你的 App 是继续运行呢还是要停下呢。data migration 分出来的话就不会出现这种问题。

后者要比前者好一些，前者依赖pg。 现在数据迁移倾向于用 rake，可以打一票 log，在 log 里输这样的进度（进度条是个伟大的发明）。不过用 rake 没有写过 reverible 的内容，目前没有遇到过类似情景。idea 非常好。以后借鉴下。thx

还没有过在 schema migration 做过 app migration。。

#2 楼 @hooopo

哦 对 确实不是一个问题

我看了那个文章，结合以前在 EMC 的经验，感觉作者将 Schema Migration 和 Data Migration 完完全全拆开肯定是不对的，当然 Rails 的做法本来也是不对的。这个问题的本质就是，都太不把 Migration 当回事了。

一般来说，一个 Migration 可能是这样的一个需求：如果是加 Column 同时赋予默认值，再设置一个 NOT NULL 约束，那么如果这几步一起做会导致整个数据库等待很长时间，期间表锁死（前提是已有的数据量很大），这显然是不合适的。因此比较好的做法是：

1. 添加 Column，但没有默认值，这样会快很多。
2. 完成之后，再给 Column 设置默认值，这样新的数据在这个 Column 上就有默认值了，之前的旧数据依然没有。
3. App 代码中已经可以开始使用这个新 Column，但必须能处理旧的数据，也就是该 Column 为 nil 的情况。
4. Data Migration 开始，为所有已有数据对该 Column 设值，这一过程通常很长，需要脚本满足可以随时暂停重启的需求（这样白天高峰期可以不 migrate）。
5. Data Migration 结束后，添加 NOT NULL 约束，所有 Column 现在都有值。
6. App 代码中移除对旧数据的处理逻辑。

作者认为 migration 需要很长时间这个说法肯定是正确的，现有的 migration 代码没有测试也确实不好。但是作者将 Schema Migration 和 Data Migration 完全拆开这个做法肯定不对，事实上，从上面的例子中可以发现，Schema Migration，Data Migration 和 App 代码相互依赖，我恨不得把 App 代码的迁移也写在 Migration 里（否则就要记得去更新代码然后重新部署），怎么可能将其分离？

所以我觉得 Rails 可能的改进点是，多段 migration，例如

class SplitNameMigration < ActiveRecord::Migration
  change 'phrase 1: migration schema' do
    # add column
    # set default value for new data
  end

  change 'phrase 2: data migration', transaction: false do
    up do
      # migrate data one by one
    end
    down do
      # rollback data one by one
    end
  end

  change 'phrase 3: migration schema again' do
    # set 'not null' for the column
  end

这个改进要求 Rails 支持 migration 存在多段并且要在数据库中记录当前 migrate 到了第几段，第二段中的 transaction: false 表示执行这段 migration 时不要自动添加 transaction，脚本自行处理 transaction，避免在中间暂停时之前迁移的数据 rollback。

当然这个改进依然不够，因为一般来说总是等 rake db:migrate 执行完毕后才启动 Rails server，但不可能等待 data migration 全部结束后才启动 Rails server，可能的做法是，在 phrase 1 结束后就自动让 Rails Server 启动，而在 Phrase 3 结束后自动控制 git 版本让它 checkout 出一个包含了对该 column 的 presence 做检查同时移除旧代码的处理逻辑的新版本然后再重启 Rails Server 就比较好了。当然这对 migration 的要求好像太高了？