在运行迁移之前是否有一种简单的方法来测试迁移？
换句话说，我想知道确保 self.down 实际上 回滚 self.up 之前的最佳方法 运行有问题的迁移。
如果我需要回滚迁移但 self.down 无法达到目的，我该怎么办？
处理潜在破坏性迁移时哪种最佳实践？ 只是数据库备份吗？
谢谢， 杜乔.
In other words I'd like to know the best way to make sure that self.down actually rolls back self.up before running the migration in question.
What can I do if I need to rollback a migration but self.down doesn't serve the purpose?
Which is the best practice when dealing with potentially destructive migrations?
Just a database backup?
Thanks,
Duccio.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您应该在不包含实时数据的开发数据库上进行开发。因此，如果数据被破坏也没关系，因为您可以轻松地再次生成它？
如果您发现自己的开发数据很重要但并不理想，那么数据库备份可能是合适的。
You should be developing on a development database which should not contain live data. Therefore it should not matter if the data is destroyed as you can easily generate it again?
A database backup might be appropriate if you find yourself in a situation where your development data is important but not ideal.
通常，迁移应仅包含架构更改。在这种情况下，它应该是非常安全的&轻松在开发/测试环境中运行迁移。如果出现问题，您始终可以重新创建数据库并用一些测试数据填充它。但是，如果您要测试一些与数据相关的迁移，那么当您实际在生产中运行它们时，可能会出现问题。
在这种情况下，正如您提到的，您应该依赖数据库备份。配备适当的 &部署前的快速恢复机制。
Typically migrations should contain only schema changes. In that case it should be very safe & easy to run the migrations in the dev/test environment. If something goes wrong you can alway re-create the database and populate it with some test data. But if you have some data related migrations to be tested, things might go wrong when you actually run them on production.
In that case as you mentioned database backup is what you should rely on. Come with a proper & quick restore mechanism before deploying.
为了确保迁移按照您想要的方式进行，您应该在开发环境中进行试验。
运行命令
以显示可用任务，例如
或
To make sure the migrations behave as you want you should experiment in your development environment.
Run the command
to show you the available tasks such as
or
每个迁移都在事务内运行。请记住这一点。这意味着，如果单个迁移中出现问题，迁移将回滚（如果有任何后续迁移，则不会执行）。
为了测试迁移，无论是
up还是down，我插入了大量的 put 语句，以检查一切是否正常工作，然后在最后一行中我提出了一个例外。这会让rails认为迁移失败，并且会回滚操作（就好像它从未发生过一样）。当我确定一切正常时，我会删除加注线并让迁移真正进行。
在您的情况下，您将测试加注，删除加注，然后不再运行它，我认为:)
希望这会有所帮助。
Each migration runs inside a transaction. Keep that in mind. That means that if something would go wrong inside a single migration, the migration is rolled back (and if there are any following they are not executed).
To test migrations, be it
upordownI insert a lot of puts-statements, to check everything has worked has supposed to, and then in my last line I raise an exception. This will make rails think the migration has failed, and it will rollback the operation (as if it never happened).When I am sure everything works as it should, I remove the raise line and let the migration really work.
In your case, you would test with the raise, remove the raise and NOT run it again I assume :)
Hope this helps.