许多人都在谈论数据库迁移,特别是有关其回滚的可能性。
我怀疑它是否有用,因为db和model的模式与应用程序逻辑(MVC)紧密相关。
假设我已经完成了一些迁移的回滚。什么?该应用程序将无法运行,因为它的逻辑完全依赖于db。
db迁移的回滚功能有哪些用例?
更新1
主要问题
当我需要更改代码时,为什么回滚会显示为功能?
我不创建迁移,例如“add_another_field_to_table”。相反,每个迁移文件都完整地描述了DB中的每个表。当我需要在我的数据库中更改某些内容时,我只需更改迁移文件,但不会将其回滚。
真的,如果我回滚迁移,它不会让我及时回到,就像版本控制一样。我有很多工作,当计划进行更改并且回滚没有给我任何东西。
答案 0 :(得分:8)
回滚的重点是您同时回滚代码和数据库。方案是您在生产服务器上升级代码和数据库,然后您发现了一个错误,您确实需要返回。因此,回滚代码并使用向下迁移来回滚数据库。
答案 1 :(得分:4)
向上迁移有什么意义?
你怎么处理这个?您必须在开发表中添加一列,测试代码,更新实时站点而不要忘记同时更新实时数据库(如果您这样做会有大错误)并且还要记住以保留现有的实时数据。如果没有类似rails的良好托管解决方案,数据库管理的这一方面可能会非常痛苦。
所以......
现在你准备发布生产....
当然,随着你添加一列,你自己也不会感到困惑。
但如果有3名程序员都添加了迁移呢?如果您有许多不同版本的实时网站怎么办?现场2或17次迁移是否落后?在保留实时数据的同时,我需要做些什么才能使数据库达到最新代码?你能看出这很快会让人感到困惑吗?
Rails迁移(实际上每个迁移系统都遵循相同的原则)旨在使更新DB结构变得非常容易。值得正确使用。
答案 2 :(得分:2)
我发现回滚只有在本地完成时才有用,即在您处理新代码时。一旦迁移已经提交到您的版本控制系统中,如果您意识到存在错误,那么它实际上无法回滚迁移,因为其他开发人员会将迁移撤下并运行它,因此您需要告诉他们回滚 - 这太难管理,也让你看起来不称职:)
更好的是在这种情况下只需要进行另一次迁移来解决问题,那么每个人(包括你的生产服务器)都会坚持使用pull& amp;迁移系统。
答案 3 :(得分:1)
不要真正理解你的问题,但我试着解释一下回滚。 如果要通过相应的迁移撤消更改,则执行回滚操作。这意味着将修改数据库,并且还将自动重新生成schema.rb。执行此操作时,您可能也想要删除引用代码。例如,如果从模型中删除了某个字段,可能您不希望在代码中引用该属性。如果您尝试访问,那么将为您提供未定义的属性异常。而已。 例如,如果之前创建了一些模型10迁移,并且想要更改某些字段,则回滚可能会变得有点麻烦。最好是创建一个新的迁移并在那里进行修改,而不是回滚到相应的迁移。
更新1
阅读您的更新,我认为您不使用迁移的主要优势,灵活性。 但是您的解决方案提供了更多数据库情况的概述。如果您愿意这样做,我建议按顺序执行以下步骤。
rake db:migrate VERSION=XXX
,我更喜欢rake db:rollback STEP = 2
,例如,回滚2次迁移,STEP
可选)rake db:migrate
)此功能不会影响您的模型或其他内容,只需更改迁移文件,重新生成schema.rb并更改数据库结构,不做任何其他操作。不能像版本控制系统一样进行代码回滚,并且没有意义去做那样的事情。您必须注意不使用已删除的字段。 Rails在数据库字段和模型属性之间具有自动映射,例如,如果user_id
表中有comment
,则可以将其称为模型中的属性comment_instance.user_id
。
希望这是有道理的。
答案 4 :(得分:0)
考虑使用capistrano部署站点并为每个部署创建带时间戳的快照的场景。使用文件夹和迁移的时间戳,您可以确定哪些版本的代码和架构齐头并进行回滚。
git存储库会为您提供类似的选项。
当然,真正的问题是,一旦站点的用户开始添加数据,那么也可能会被清除,除非您在回滚之前备份它并在以后精心恢复它。
答案 5 :(得分:0)
我在处理迁移代码时以及最终提交之前使用rake db:migrate:redo
本地迁移回滚。