什么时候可以在迁移的 self.down 方法中引发 ActiveRecord::IrreversibleMigration 异常？您什么时候应该努力实际实现相反的迁移？
最佳答案
如果您正在处理生产级系统，那么是的，这非常糟糕。如果这是您自己的宠物项目，那么任何事情都是允许的(如果没有别的，这将是一次学习经历:)，尽管很可能迟早，即使在一个宠物项目中，您也会发现自己已经在一个反向迁移只需在几天后撤消该迁移，无论是通过 rake 还是手动。)
在生产场景中，您应该始终努力编写并测试可逆迁移，以防万一您在生产中经历它，然后发现错误这迫使您回滚(代码和架构)到之前的某个版本(等待一些重要的修复 - 以及否则无法使用的生产系统。)
反向迁移的范围从大多微不足道(删除迁移期间添加的列或表，和/或更改列类型等)到稍微复杂一些(执行 JOINed INSERT 或 UPDATE )，但没有什么复杂到可以证明“将其隐藏起来”的合理性。如果不出意外的话，强制自己思考实现反向迁移的方法可以让您对正向迁移正在解决的问题有新的见解。
您有时可能会遇到正向迁移删除某个功能的情况，从而导致数据从数据库中被丢弃。 由于显而易见的原因，反向迁移无法恢复丢弃的数据。尽管在这种情况下，我们可以建议让正向迁移自动保存数据或在可能发生回滚时保留数据，作为彻底的替代方法失败(保存到 yml、复制/移动到特殊表等)，您不必这样做，因为测试此类自动化过程所需的时间可能超过恢复该过程所需的时间手动数据(如果需要的话)。但即使在这种情况下，您也可以随时使反向迁移有条件且暂时失败，而不仅仅是失败，以等待某些用户操作(即测试是否存在某些必须手动恢复的必需表；如果丢失，则输出“我失败了，因为我无法从虚无中重新创建表XYZ；手动恢复表XYZ” > 从备份中再次运行我，我不会让你失望的!”)
关于ruby-on-rails - rails : Is it bad to have an irreversible migration?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/621257/