迁移脚本如何应用于 Rails 2.1 及更高版本？
我（目前）不是 Rails 开发人员，所以请原谅我对此的无知。
我一直喜欢 Rails 的一件事是迁移以及它如何满足所有语言和平台的共同需求。 话虽如此，我很想了解 2.1 中所做的更改会导致特定场景的结果。
据我所知，Rails 2.1 及更高版本对迁移逻辑进行了两处更改。 第一个是在生成时使用基于时间戳的脚本名称，以减少 2 个开发人员在将文件添加到源代码管理之前同时处理同一文件的可能性。 因此，生成脚本时，现在是 20090729123456_test.rb，而不是 002_test.rb。
第二项是 Schema_Info 表被替换为 Schema_Migrations 表，该表显示迁移列表，而不仅仅是最新版本号。
查看 Rails 源代码，我注意到它将模式的“当前版本”作为 Schema_Migration 表中找到的最大版本。
这是我试图弄清楚的场景：
开发人员 A 生成一个新脚本：20090729120000_test.rb。
开发者B生成一个新脚本：20090729130000_test.rb。
开发人员 B 首先将其脚本迁移到数据库，方法是不指定版本号并假设开发人员 A 的脚本尚未添加。
当开发人员 A 添加他的脚本并尝试迁移到最新版本时，由于他的脚本版本（基于时间戳）低于当前应用的版本，会发生什么情况？
I'm not a Rails developer (currently) so please forgive my ignorance on this.
One thing I've always liked about Rails is migrations and how it fills a need that's common across all languages and platforms. With that said, I am curious to understand what a certain scenario would result with the changes made in 2.1.
Rails 2.1 and higher, from what I can tell, made two changes to the migrations logic. The first was to use timestamp based script names when generated in order to reduce the probability of 2 developers working on the same file at the same time before adding the file to source control. So instead of 002_test.rb, it is now 20090729123456_test.rb when the script is generated.
The second item was that the Schema_Info table was replaced with the Schema_Migrations table that presented a list of migrations and not just the latest version number.
Looking through the Rails source, I noticed that it took the "current version" of the schema as the max version found in the Schema_Migration table.
Here's the scenario I'm trying to figure out:
Developer A generates a new script: 20090729120000_test.rb.
Developer B generates a new script: 20090729130000_test.rb.
Developer B migrates his script to the database first by not specifying the version number and assuming that Developer A's script isn't added yet.
What happens when Developer A adds his script and tries to migrate to the latest version since his script version (based on the time stamp) is less than the currently applied version now?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我并不肯定，但我相信他必须执行“rake db:rollback”来撤消开发人员 B 迁移，然后运行“rake db:migrate”以正确的顺序执行这两个操作。 当然，如果两个开发人员独立处理不需要彼此集成的表（如本例所示，因为开发人员 B 不必等待开发人员 A 运行其迁移），开发人员 A 可以简单地将一个添加到开发者 B 迁移的时间戳，它将再次保持正确的顺序。
I'm not positive, but I believe that he would have to do a "rake db:rollback" to undo the Developer B migration, then run "rake db:migrate" to do both of them in the proper order. Of course, if two developers are working independently on tables that require no integration with one another (as this case shows, since Developer B didn't have to wait for Developer A to run his migration), developer A can simply add one to the timestamp of Developer B's migration and it will be in proper order once again.
简短的回答是：不用担心。
rake db:migrate 将尝试运行 schema_migrations 表中未找到的任何迁移。 是否已经运行了较新的迁移并不重要。
如果 B 依赖于 A 并且必须按该顺序运行，那么您可能会遇到问题，但这是开发人员之间的问题。
The short answer is: don't worry about it.
rake db:migrate will attempt to run any migrations that are not found in the schema_migrations table. It doesn't matter if there are newer migrations that have already been run.
If B is dependent on A and must be run in that order, then you might have a problem, but that's an issue between the developers.