The point of rollback is that you rollback code and DB at the same time. The scenario is you upgrade your code and your DB on your production server, then you find a bug and you really need to go back. So rollback your code and use your down migration to roll back your DB.
Oh, wait, they want a new feature that involves adding a column to an existing table.
How do you handle this? You have to add a column to your development tables, test code, update live site without forgetting to update live DB at the same time (cos if you do there will be big errors) And also remmember to preserve existing live data. This aspect of DB management can be a real pain without a nice managed solution like rails has.
So ...
Code a one line migration that adds a column
Run migration on dev copy, scehma.rb will update
Code new features, if you need to check DB schema use schema.rb NOT migration files.
Now your ready to release on production ....
Update code on production
Run migrations on production. Rails will automatically work out what needs to be applied and do it for you!
Sure, with you adding one column it's not that confusing to do it yourself.
But what if there were 3 programmers all adding migrations? What if you have many live sites, all at different versions? Is that live site 2 or 17 migrations behind? What do I have to do to get the DB up to the latest code, whilst preserving live data? Can you see how this would very quickly get confusing to deal with?
Rails migrations (and practically every migration system works on the same principles) are designed to make updating DB structures really easy. Well worth using properly.
I've found that rollbacks are only useful if they are done locally, ie while you're working on a new bit of code. Once a migration has been committed into your version control system, if you realise there was a mistake then it doesn't really work to roll back the migration because other developers will have pulled the migration down and run it, so you'd need to tell them to roll back as well - this is too difficult to manage and also makes you look incompetent :)
Better in this situation to just do another migration to fix the problem, then everyone (including your production server) just sticks with the pull & migrate system.
Don't really understand your problem, but i try to explain a bit the rollback. You do rollback if you want to undo the changes by the respective migration. This means that the database will be modified, and also your schema.rb will be automatically regenerated. When you do this probably you want to remove the referencing code too. For example if you removed a field from the model, probably you don't want to refer to that attribute in your code. If you try to access then will gives you undefined attribute exception. That's it. Can become a bit cumbersome to rollback for example if you created some model 10 migrations before, and you want to change some fields. It's better to create a new migration and modify there, instead of rolling back to the respective migration.
Update 1
Read your update, and i think yo don't use the main advantage of migrations, the flexibility. But your solution gives more overview of the database situation. If you like to do that way, I suggest the following steps in order.
Roll back to the respective migration.(rake db:migrate VERSION=XXX, I like better rake db:rollback STEP = 2 for example, rolls back 2 migrations, STEP optional)
Make your changes
Migrate your database to update all the tables, and get to current migration version.(rake db:migrate)
This feature don't affect your models or something, just changes the migration file, regenerates your schema.rb and changes the database structure, nothing else. Can't do code rollback like with version control system, and don't really has sense to do something like that. You have to take care about not using removed fields. Rails has automated mapping between database fields and model attibutes, for example if you have an user_id in your comment table, you can call it as an attribute in your model, comment_instance.user_id.
Consider a scenario where you use capistrano to deploy your site and create timestamped snapshots of each deployment. Using the timestamp on the folder and your migrations, you could identify which versions of the code and schema go hand in hand and perform a rollback.
A git repository would give you similar options.
Of course, the real problem is that once users of a site start adding data, that will potentially get purged too, unless you back it up before a rollback and painstakingly restore it at a later date.
发布评论
评论（6）
回滚的重点是同时回滚代码和数据库。这种情况是，您升级生产服务器上的代码和数据库，然后您发现一个错误，并且确实需要返回。因此，回滚您的代码并使用向下迁移来回滚您的数据库。
The point of rollback is that you rollback code and DB at the same time. The scenario is you upgrade your code and your DB on your production server, then you find a bug and you really need to go back. So rollback your code and use your down migration to roll back your DB.
向上迁移的意义是什么？
你如何处理这个问题？您必须在开发表中添加一列，测试代码，更新实时站点，同时不要忘记更新实时数据库（因为如果这样做，将会出现很大的错误），并且还要记住保留现有的实时数据。如果没有像 Rails 这样良好的托管解决方案，数据库管理的这方面可能会非常痛苦。
所以...
现在您已准备好在生产环境中发布....
当然，当您添加一列时，您自己添加一列并不那么令人困惑。
但是如果有 3 名程序员都添加迁移怎么办？如果您有许多实时站点，并且都具有不同的版本怎么办？该实时站点是否落后于 2 或 17 迁移？我需要做什么才能使数据库更新到最新代码，同时保留实时数据？你能看出这会很快变得令人困惑吗？
Rails 迁移（实际上每个迁移系统都遵循相同的原理）旨在使更新数据库结构变得非常容易。非常值得正确使用。
What are the point of Up migrations?
How do you handle this? You have to add a column to your development tables, test code, update live site without forgetting to update live DB at the same time (cos if you do there will be big errors) And also remmember to preserve existing live data. This aspect of DB management can be a real pain without a nice managed solution like rails has.
So ...
Now your ready to release on production ....
Sure, with you adding one column it's not that confusing to do it yourself.
But what if there were 3 programmers all adding migrations? What if you have many live sites, all at different versions? Is that live site 2 or 17 migrations behind? What do I have to do to get the DB up to the latest code, whilst preserving live data? Can you see how this would very quickly get confusing to deal with?
Rails migrations (and practically every migration system works on the same principles) are designed to make updating DB structures really easy. Well worth using properly.
我发现回滚只有在本地完成时才有用，即当您正在编写新的代码时。一旦将迁移提交到版本控制系统中，如果您意识到存在错误，那么回滚迁移实际上并不起作用，因为其他开发人员将拉下迁移并运行它，因此您需要告诉他们也回滚 - 这太难管理了，而且会让你看起来无能:)
在这种情况下最好做另一次迁移来解决问题，然后每个人（包括你的生产服务器）都坚持拉动;迁移系统。
I've found that rollbacks are only useful if they are done locally, ie while you're working on a new bit of code. Once a migration has been committed into your version control system, if you realise there was a mistake then it doesn't really work to roll back the migration because other developers will have pulled the migration down and run it, so you'd need to tell them to roll back as well - this is too difficult to manage and also makes you look incompetent :)
Better in this situation to just do another migration to fix the problem, then everyone (including your production server) just sticks with the pull & migrate system.
不太明白你的问题，但我尝试解释一下回滚。
如果您想撤消相应迁移所做的更改，请执行回滚。这意味着数据库将被修改，并且您的 schema.rb 将自动重新生成。当您执行此操作时，您可能也想删除引用代码。例如，如果您从模型中删除了一个字段，您可能不想在代码中引用该属性。如果您尝试访问，则会出现未定义属性异常。就是这样。
例如，如果您之前创建了一些模型 10 迁移，并且想要更改某些字段，那么回滚可能会变得有点麻烦。最好创建一个新的迁移并在那里进行修改，而不是回滚到相应的迁移。
更新 1
阅读您的更新，我认为您没有利用迁移的主要优势，即灵活性。
但您的解决方案提供了对数据库情况的更多概述。如果您喜欢这样做，我建议按顺序执行以下步骤。
rake db:migrate VERSION=XXX，我更喜欢rake db:rollback STEP = 2例如，回滚 2 个迁移，STEP可选）rake db:migrate）此功能不会影响您的模型或其他内容，只是更改迁移文件，重新生成 schema.rb 并更改数据库结构，仅此而已。无法像版本控制系统那样进行代码回滚，并且确实没有意义做类似的事情。您必须注意不要使用已删除的字段。 Rails 具有数据库字段和模型属性之间的自动映射，例如，如果您的
comment表中有一个user_id，您可以将其作为模型中的属性进行调用，comment_instance.user_id。Don't really understand your problem, but i try to explain a bit the rollback.
You do rollback if you want to undo the changes by the respective migration. This means that the database will be modified, and also your schema.rb will be automatically regenerated. When you do this probably you want to remove the referencing code too. For example if you removed a field from the model, probably you don't want to refer to that attribute in your code. If you try to access then will gives you undefined attribute exception. That's it.
Can become a bit cumbersome to rollback for example if you created some model 10 migrations before, and you want to change some fields. It's better to create a new migration and modify there, instead of rolling back to the respective migration.
Update 1
Read your update, and i think yo don't use the main advantage of migrations, the flexibility.
But your solution gives more overview of the database situation. If you like to do that way, I suggest the following steps in order.
rake db:migrate VERSION=XXX, I like betterrake db:rollback STEP = 2for example, rolls back 2 migrations,STEPoptional)rake db:migrate)This feature don't affect your models or something, just changes the migration file, regenerates your schema.rb and changes the database structure, nothing else. Can't do code rollback like with version control system, and don't really has sense to do something like that. You have to take care about not using removed fields. Rails has automated mapping between database fields and model attibutes, for example if you have an
user_idin yourcommenttable, you can call it as an attribute in your model,comment_instance.user_id.考虑这样一个场景：您使用 capistrano 部署站点并为每个部署创建带时间戳的快照。使用文件夹和迁移上的时间戳，您可以确定哪些版本的代码和架构齐头并进并执行回滚。
git 存储库将为您提供类似的选项。
当然，真正的问题是，一旦站点的用户开始添加数据，这些数据也可能会被清除，除非您在回滚之前对其进行备份并在以后煞费苦心地恢复它。
Consider a scenario where you use capistrano to deploy your site and create timestamped snapshots of each deployment. Using the timestamp on the folder and your migrations, you could identify which versions of the code and schema go hand in hand and perform a rollback.
A git repository would give you similar options.
Of course, the real problem is that once users of a site start adding data, that will potentially get purged too, unless you back it up before a rollback and painstakingly restore it at a later date.
在处理迁移代码时和最终提交之前，我在本地使用 rake db:migrate:redo 进行迁移回滚。
I use migration rollback locally with
rake db:migrate:redowhile working on migration code and before final commit.