Rails:进行不可逆转的迁移是不是很糟糕? [英] Rails: Is it bad to have an irreversible migration?

问题描述

何时可以在迁移的 self.down 方法中引发 ActiveRecord::IrreversibleMigration 异常?您应该在什么时候努力实际实施迁移的逆向操作?

When is it acceptable to raise an ActiveRecord::IrreversibleMigration exception in the self.down method of a migration? When should you take the effort to actually implement the reverse of the migration?

推荐答案

如果您正在处理生产级系统，那么是的，这是非常糟糕的.如果这是您自己的宠物项目，那么任何事情都是允许的(如果没有别的，这将是一种学习体验 :) 尽管迟早，即使在宠物项目中，您也会发现自己已经跨越了反向迁移只是必须在几天后撤消该迁移，无论是通过 rake 还是手动.)

If you are dealing with production-grade systems then yes, it is very bad. If it is your own pet project, then anything is allowed (if nothing else, it will be a learning experience :) though chances are that sooner rather than later, even in a pet project, you will find yourself having put a cross over a reverse migration only to have to undo that migration a few days later, be it via rake or manually.)

在生产场景中，您应该始终努力编写和测试可逆迁移，以防万一在生产环境中通过它，然后发现错误这会迫使您回滚(代码 和 架构)到某个先前的修订版(等待一些重要的修复——以及其他无法使用的生产系统.)

In a production scenario, you should always make the effort to write and test a reversible migration in the eventuality that you go through it in production, then discover a bug which forces you to roll back (code and schema) to some previous revision (pending some non-trivial fix -- and an otherwise unusable production system.)

反向迁移的范围从大多数微不足道的(删除在迁移期间添加的列或表，和/或更改列类型等)到更复杂的(execute of JOINed INSERTs 或 UPDATEs)，但没有什么比把它扫到地毯下"更复杂的了.如果不出意外，强迫自己思考实现反向迁移的方法可以让您对正向迁移正在解决的问题有新的认识.

Reverse migrations range from mostly trivial (removing columns or tables that were added during migration, and/or changing column types, etc.) to somewhat more involved (execute of JOINed INSERTs or UPDATEs), but nothing is so complex as to justify "sweeping it under the rug". If nothing else, forcing yourself to think of ways to achieve reverse migrations can give you new insight into the very problem that your forward migration is fixing.

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

You might occasionally run into a situation where a forward migration removes a feature, resulting in data being discarded from the database. For obvious reasons, the reverse migration cannot resuscitate discarded data. Although one could, in such cases, recommend having the forward migration automatically save the data or keep it around in the eventuality of rollback as an alternative to outright failure (save to yml, copy/move to a special table, etc.), you don't have to, as the time required to test such an automated procedure could exceed the time required to restore the data manually (should the need arise.) But even in such cases, instead of just failing, you can always make the reverse migration conditionally and temporarily fail pending some user action (i.e. test for the existence of some required table that has to be restored manually; if missing, output "I have failed because I cannot recreate table XYZ from nothingness; manually restore table XYZ from backup then run me again, and I will not fail you!")

这篇关于Rails:进行不可逆转的迁移是不是很糟糕?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！