ActiveRecord::Schema.define info :schema.rb 中的版本 -->有必要顺序吗?

发布于 2024-12-18 07:33:37 字数 378 浏览 2 评论 0 原文

在rails db创建脚本schema.rb中,顶部有这一行:

ActiveRecord::Schema.define(:version => 20111127090505) do

文档(http://api.rubyonrails.org/classes/ActiveRecord/Schema.html)说 info hash param 是可选的

  • :version 的用途是什么?
  • 签到时是否需要增加这个数字?即,当天晚些时候签入会使版本号下降...
  • 如果存在时间戳大于给定的迁移,它们是否会仅仅因为它们不在迁移表中而运行,但类文件存在?
  • 迁移文件是否按顺序运行?

In the rails db creation script schema.rb, there is this line at the top:

ActiveRecord::Schema.define(:version => 20111127090505) do

The docs (http://api.rubyonrails.org/classes/ActiveRecord/Schema.html) say that the
info hash param is optional

  • What is :version used for?
  • Is there any need for this number to be increasing on checkins? I.e., checkin later in the day makes the version number go down...
  • If there are migrations with timestamps greater than given, will they be run run simply because they are not in the migration table, yet the class file exists?
  • Are migration files run sequentially?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一杯敬自由 2024-12-25 07:33:37

该版本用于确定上次运行的迁移。随着时间的推移,这种情况只会增加。您在此处运行的迁移是在 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.

¢好甜 2024-12-25 07:33:37

从基于分支的开发(使用 git 和 github PR)的角度来看,我也想知道这个问题。

如下所示,rails确实可以处理架构版本中缺乏更改的情况,并且会正确地注意到尚未应用较旧的迁移。


给定以下功能分支“F”的变基:

o
| \
|  F  # migration on Feature branch
A     # other migration merged to main first

功能分支的变基会导致版本上的 schema.rb 发生冲突。按照 migrate+dump 解决该问题created-by-git-operation/7614339#7614339">管理Git操作创建的schema.rb中的冲突

$ git checkout main
$ rails db:migrate      # apply new migration from commit A on main branch
$ git checkout feature
$ git rebase main       # stops on conflict
$ rails db:migrate && rails db:schema:dump  # overwrite conflicted schema file
$ git add db/schema.rb  # mark conflict as resolved
$ git rebase --continue
o
|
|
A     # other migration merged to main first
F'    # rebased B, no longer has diff on schema

然后检查迁移状态,显示rails 确实了解,如果不依赖 schema.rb 中的版本信息,则尚未运行“较旧”的迁移之一。

$ rails db:migrate:status | tail -n 5
   up     20210609094438  Add access booleans to token
  down    20210610090328  Add uplift to early career teacher profile
   up     20210611133458  Change default api token type
   up     20210611141524  Update e and l tokens with private access

生成的架构补丁,请注意版本上没有差异:

diff --git a/db/schema.rb b/db/schema.rb
index 4523b11b..c7bbd6e0 100644
--- a/db/schema.rb
+++ b/db/schema.rb
@@ -153,0 +154 @@ ActiveRecord::Schema.define(version: 2021_06_11_141524) do
+    t.boolean "uplift", default: false, null: false

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":

o
| \
|  F  # migration on Feature branch
A     # other migration merged to main first

A rebase of the feature branch results in a conflict on schema.rb on the version. Resolving it with a migrate+dump as per Managing conflict in schema.rb created by Git operation :

$ git checkout main
$ rails db:migrate      # apply new migration from commit A on main branch
$ git checkout feature
$ git rebase main       # stops on conflict
$ rails db:migrate && rails db:schema:dump  # overwrite conflicted schema file
$ git add db/schema.rb  # mark conflict as resolved
$ git rebase --continue
o
|
|
A     # other migration merged to main first
F'    # rebased B, no longer has diff on schema

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.

$ rails db:migrate:status | tail -n 5
   up     20210609094438  Add access booleans to token
  down    20210610090328  Add uplift to early career teacher profile
   up     20210611133458  Change default api token type
   up     20210611141524  Update e and l tokens with private access

The resultant schema patch, note that there is no diff on the version:

diff --git a/db/schema.rb b/db/schema.rb
index 4523b11b..c7bbd6e0 100644
--- a/db/schema.rb
+++ b/db/schema.rb
@@ -153,0 +154 @@ ActiveRecord::Schema.define(version: 2021_06_11_141524) do
+    t.boolean "uplift", default: false, null: false

Tested on Rails 6.1.3.2

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文