ActiveRecord::Schema.define info :schema.rb 中的版本 -->有必要顺序吗?
在rails db创建脚本schema.rb中,顶部有这一行:
ActiveRecord::Schema.define(:version => 20111127090505) do
文档(http://api.rubyonrails.org/classes/ActiveRecord/Schema.html)说 info hash param 是可选的
- :version 的用途是什么?
- 签到时是否需要增加这个数字?即,当天晚些时候签入会使版本号下降...
- 如果存在时间戳大于给定的迁移,它们是否会仅仅因为它们不在迁移表中而运行,但类文件存在?
- 迁移文件是否按顺序运行?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
该版本用于确定上次运行的迁移。随着时间的推移,这种情况只会增加。您在此处运行的迁移是在 UTC 时间 2011 年 11 月 27 日上午 09:05:05创建(而不是运行)。这就是数字:时间戳。
每次运行新创建的迁移时,该数字都会增加,这样 Rails 就会知道哪一个是最后运行的以及下一个要运行的。下一次要运行的迁移将是第一个迁移的数量大于此数量的迁移。
是的,迁移文件按照创建的顺序运行。
The version is used to determine what migration was run last. This will only increase over time. The migration you've run here was created (not run) on the 27th November, 2011 at 09:05:05AM in UTC time. This is what the number is: a timestamp.
The number will increase every time you run a newly created migration, this is so Rails will know which one has run last and which one to run next. The next migration to be run will be the one with the first one with the greater number than this number.
And yes, migration files are run in the order they are created.
从基于分支的开发(使用 git 和 github PR)的角度来看,我也想知道这个问题。
如下所示,rails确实可以处理架构版本中缺乏更改的情况,并且会正确地注意到尚未应用较旧的迁移。
给定以下功能分支“
F
”的变基:功能分支的变基会导致版本上的
schema.rb
发生冲突。按照 migrate+dump
解决该问题created-by-git-operation/7614339#7614339">管理Git操作创建的schema.rb中的冲突:然后检查迁移状态,显示rails 确实了解,如果不依赖
schema.rb
中的版本信息,则尚未运行“较旧”的迁移之一。生成的架构补丁,请注意版本上没有差异:
在
Rails 6.1.3.2
上测试I was wondering about this too from the point of view of branch-based development (with git and github PRs).
As shown below rails does cope with the lack of change in the schema version, and will correctly notice that an older migration has not yet been applied.
Given the following rebase of a feature branch "
F
":A rebase of the feature branch results in a conflict on
schema.rb
on the version. Resolving it with amigrate
+dump
as per Managing conflict in schema.rb created by Git operation :and then checking the migration status, shows that rails does understand that one of the "older" migrations has not been run without relying on the version information in
schema.rb
.The resultant schema patch, note that there is no diff on the version:
Tested on
Rails 6.1.3.2