Rails：不可逆转的迁移是不是很糟糕？

Question

什么时候可以在迁移的 self.down 方法中引发 ActiveRecord::IrreversibleMigration 异常？ 您什么时候应该努力实际实施相反的迁移？

Answer 1

如果您正在处理生产级系统，那么是的，这非常糟糕。 如果这是您自己的宠物项目，那么任何事情都是允许的（如果没有别的，这将是一次学习经历:)，尽管很可能迟早，即使在一个宠物项目中，您也会发现自己已经在一个反向迁移只需在几天后撤消该迁移，无论是通过 rake 还是手动。）

在生产场景中，您应该始终努力编写和测试 一个可逆的迁移，如果您在生产中经历它，然后发现一个错误，迫使您回滚（代码和架构）到某个先前的修订（待定）一些重要的修复 - 以及否则无法使用的生产系统。）

反向迁移的范围从大部分微不足道（删除迁移期间添加的列或表，和/或更改列类型等）到稍微复杂一些（JOIN 的 INSERT 或 UPDATE 的执行），但是没有什么复杂到可以证明“将其隐藏起来” ”。 如果不出意外的话，强迫自己思考实现反向迁移的方法可以让您对正向迁移正在解决的问题有新的见解。

您有时可能会遇到前向迁移删除某个功能的情况，从而导致数据从数据库中被丢弃。 由于显而易见的原因，反向迁移无法恢复丢弃的数据。尽管在这种情况下，我们可以建议让正向迁移自动保存数据或在可能发生回滚时保留数据，作为彻底的替代方法失败（保存到 yml、复制/移动到特殊表等），您不必这样做，因为测试此类自动化过程所需的时间可能超过恢复该过程所需的时间手动数据（如果需要的话）。但即使在这种情况下，您也可以随时使反向迁移有条件且暂时失败，而不仅仅是失败，以等待某些用户操作（即测试是否存在某些必须手动恢复的表，如果丢失，则输出“我失败了，因为我无法从虚无中重新创建表XYZ；手动恢复表XYZ 从备份中再次运行我，我不会让你失望的！”）

Answer 2

如果要销毁数据，可以先进行备份。
例如

def self.up
  # create a backup table before destroying data 
  execute %Q[create table backup_users select * from users]  
  remove_column :users, :timezone
end  

def self.down
  add_column :users, :timezone, :string  
  execute %Q[update users U left join backup_users B on (B.id=U.id) set U.timezone = B.timezone]
  execute %Q[drop table backup_users]  
end

Answer 3

在生产场景中，您应该始终努力编写和测试可逆迁移，以防万一您在生产中经历它，然后发现一个错误，迫使您回滚（代码和架构）到以前的某个版本修订（等待一些重要的修复——以及否则无法使用的生产系统。）

可逆迁移对于开发和登台来说是很好的，但假设代码经过良好测试，那么您想要在生产中迁移的情况应该是极其罕见的。 我在生产模式下在迁移中构建了自动不可逆迁移。 如果我确实需要撤销更改，我可以使用另一个“向上”迁移或删除异常。 但这似乎很粗略。 任何会导致如此可怕的情况的错误都表明质量检查流程严重混乱。

Answer 4

感觉您需要不可逆转的迁移可能表明您面临着更大的问题。 也许一些细节会有帮助？

至于你的第二个问题：我总是花“努力”来写迁移的反向内容。 当然，我实际上并没有编写.down，TextMate 在创建.up 时自动插入它。

Answer 5

可逆数据迁移让您可以轻松使用 yaml 文件创建可逆数据迁移。

class RemoveStateFromProduct < ActiveRecord::Migration
  def self.up
    backup_data = []
    Product.all.each do |product|
      backup_data << {:id => product.id, :state => product.state}
    end
    backup backup_data
    remove_column :products, :state
  end
  def self.down
    add_column :products, :state, :string
    restore Product
  end
end

Answer 6

IIRC，在迁移中更改数据类型时，您将拥有 IrreversibleMigration。

Answer 7

我认为另一种可以接受的情况是当您进行整合迁移时。 在这种情况下，“向下”实际上没有意义，因为它会删除所有表（合并后添加的表除外）。 这可能不是你想要的。