Rails：“schema.rb”中的版本号是否用于任何东西？ [英] Rails: Is the version number in 'schema.rb' used for anything?

问题描述

现在Rails有带有时间戳的迁移时， /db/schema.rb 顶部的单一版本号似乎毫无意义。有时，当处理多个开发人员或多个分支时，版本号不正确。

Rails是否使用：version 参数了吗？

并且有任何不正确的伤害（因为它不反映最近应用的提交的时间戳）？

例如：

  ActiveRecord :: Schema.define（：version => 20100417022947）do 
＃schema definition ... 
 end 
  

解决方案

实际上，版本比这更重要。你引用的代码实际上只是assume_migrated_upto_version的一小部分。迁移版本的真正效果是，假定已经运行所有以前的迁移 （位于db / migrate目录中） （所以是的，它做的功能名称建议。）

这有一些有趣的影响，特别是在多人同时提交新的迁移的情况下。 / p>

如果你的版本是schema.rb，这是Rails团队推荐的，你可以。您100％保证有冲突（架构版本），提交/合并用户必须通过合并其更改并将：版本设置为两者中的最高值来解决它。希望他们能够正确合并。

有些项目选择避免这种持续的冲突问题，保持schema.rb的版本控制。

如果有人创建了一个迁移，并且时间戳记为之前添加到您的schema.rb's：版本。如果你的db：migrate，你将应用他们的迁移，你的schema.rb将被更新（但保持相同，更高：版本），一切都很好。但是，如果您应该发生在db：schema：load（或db：reset），则不仅会丢失其迁移，而且 assume_migrated_upto_version会将其迁移标记为已应用。

此时的最佳解决方案可能是要求用户将其迁移时间重新标记为合并时间。

理想情况下，我更喜欢如果schema.rb实际上包含应用的迁移数字的列表，而不是一个承担到这里：版本。但我怀疑这会发生--Rails团队似乎相信这个问题已通过检查schema.rb文件充分解决。

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

解决方案

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.rb”中的版本号是否用于任何东西？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！