Rails：是“schema.rb”中的版本号；用于什么？
现在 Rails 已经有了 带时间戳的迁移，/db/schema.rb顶部的单个版本号似乎毫无意义。有时，在处理多个开发人员或多个分支时，版本号最终会不正确。
Rails 是否还使用 :version 参数？
它不正确有什么危害吗（例如：它不反映最近应用的提交的时间戳）？
例子：
ActiveRecord::Schema.define(:version => 20100417022947) do
# schema definition ...
end
Now that Rails has timestamped migrations, the single version number at the top of /db/schema.rb seems pointless. Sometimes the version number ends up incorrect when dealing with multiple developers or multiple branches.
Does Rails even utilize that :version parameter anymore?
And is there any harm in it being incorrect (as in: it doesn't reflect the timestamp of most recently applied commit)?
Example:
ActiveRecord::Schema.define(:version => 20100417022947) do
# schema definition ...
end
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实上，版本比这个重要得多。您引用的代码实际上只是假设_迁移_upto_版本所做的一小部分。迁移版本的真正效果是，所有先前的迁移（在 db/migrate 目录中找到） 假定已运行。 （所以，是的，它执行函数名称所暗示的功能。）
这有一些有趣的含义，特别是在多人同时提交新迁移的情况下。
如果您按照 Rails 团队的建议对 schema.rb 进行版本控制，那就没问题。您 100% 保证会发生冲突（架构版本），提交/合并用户必须通过合并他们的更改并将 :version 设置为两者中的最高版本来解决它。希望他们能正确地进行合并。
一些项目选择通过将 schema.rb 置于版本控制之外来避免这种持续的冲突问题。他们可能仅依赖于迁移，或者保留偶尔更新的架构的单独版本控制副本。
如果有人创建时间戳早于您的 schema.rb 的 :version 的迁移，则会出现此问题。如果您 db:migrate，您将应用它们的迁移，您的 schema.rb 将被更新（但保留相同的、更高的：版本），并且一切都很好。但是，如果您碰巧使用 db:schema:load （或 db:reset），您不仅会错过它们的迁移，而且 assume_migerated_upto_version 会将它们的迁移标记为已应用。
最佳解决方案此时可能需要用户将其迁移重新标记为合并时间。
理想情况下，我更希望 schema.rb 实际上包含已应用的迁移编号的列表，而不是假设的版本：版本。但我怀疑这种情况会发生——Rails 团队似乎相信通过检查 schema.rb 文件可以充分解决问题。
Actually, the version is much more important than this. The code you've cited is actually only a small part of what assume_migrated_upto_version does. The real effect of the migration version is that all prior migrations (as found in the db/migrate directory) are assumed to have been run. (So yes, it does what the function name suggests.)
This has some interesting implications, particularly in the case where multiple people commit new migrations at the same time.
If you version your schema.rb, which is what the Rails team recommends, you're okay. You're 100% guaranteed to have a conflict (the schema version), and the committing/merging user has to resolve it, by merging their changes and setting the :version to the highest of the two. Hopefully they do this merge correctly.
Some projects choose to avoid this continual conflict issue by keeping the schema.rb out of version control. They might rely solely on migrations, or keep a separate version-controlled copy of the schema that they occasionally update.
The problem occurs if someone creates a migration with a timestamp prior to your schema.rb's :version. If you db:migrate, you'll apply their migration, your schema.rb will be updated (but retain the same, higher :version), and everything is fine. But if you should happen to db:schema:load (or db:reset) instead, you'll not only be missing their migration, but assume_migrated_upto_version will mark their migration as having been applied.
The best solution at this point is probably to require that users re-timestamp their migrations to the time of their merge.
Ideally, I would prefer if schema.rb actually contained a list of applied migration numbers rather than an assume-up-to-here :version. But I doubt this will happen -- the Rails team seems to believe the problem is adequately solved by checking in the schema.rb file.
我决定自己调查一下。事实证明，由于带有时间戳的迁移，Rails 使用该数字所做的唯一的事情是假设具有该特定时间戳的迁移已被应用，从而创建适当的迁移schema_migration 表中的条目（如果不存在）。
来自：/lib/active_record/connection_adapters/abstract/schema_statements.rb
I decided to investigate myself. It turns out that because of the timestamped migrations, the only thing Rails does with that number is assume that the migration with that particular timestamp has already been applied and thus create the appropriate entry in the schema_migration table if it doesn't exist.
from:
/lib/active_record/connection_adapters/abstract/schema_statements.rb