db：schema：load如何影响将来的db：migrate操作

Question

假设我有一个带有大量迁移文件的应用程序，我已准备好第一次部署到生产环境中。根据我的理解，我基本上有两个选项可以在生产服务器上运行db：

• A - 运行db:migrate，让它循环完成尚未运行的所有迁移
• B - 运行db:schema:load，让它从模式文件构建数据库

我知道B是新部署的正确选择，如schema.rb评论中所述：

# If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).

我想知道的是，这对生产服务器上的迁移有何影响？例如，如果我按顺序执行以下操作：

1. 在新的生产服务器上运行db:schema:load。
2. 在开发中更改我的架构并推向生产。
3. 在生产服务器上运行db:migrate

会发生什么？是否知道仅使用比db:schema:load操作更新的迁移，还是会尝试全部运行？

Answer 1

好问题。答案是，只有在最新的db:schema:load事件之后创建的迁移才能运行。

schema.rb 文件有一个与之关联的版本标记：

ActiveRecord::Schema.define(version: 20130928225041) do ...

当您运行db:schema:load时，Rails会根据该schema.rb文件创建一个新数据库，同时使用版本号先于模式的所有迁移填充schema_migrations表。 。

据我所知，Rails实际上是伪造所有迁移，直到那时为止，但实际上并没有运行它们。 （我通过生成一个空的迁移文件，在本地调用db:migrate，然后在将迁移文件部署到我们的服务器之前将错误插入到迁移文件中来测试它。在服务器上，我们运行了db:schema:load，并且结果是，错误的迁移包含在schema_migrations表中，就像它已经运行一样，即使它显然没有。）