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 JOIN ed INSERT s或 s)，但没有什么复杂的东西可以证明在地毯下扫一扫".如果没有其他问题，强迫自己思考实现反向迁移的方法可以使您对正向迁移正在解决的问题有新的认识.

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屋！