【问题标题】:How does db:schema:load affect future db:migrate actionsdb:schema:load 如何影响未来的 db:migrate 操作
【发布时间】:2013-09-30 01:14:47
【问题描述】:

假设我有一个包含大量迁移文件的应用,我正准备首次将其部署到生产环境。据我了解,我基本上有两种选择可以在生产服务器上启动数据库:

  • A - 运行 db:migrate,并让它循环执行所有尚未运行的迁移
  • B - 运行db:schema:load,并让它从架构文件构建数据库

我知道 B 是新部署的正确选择,如 schema.rb cmets 中所述:

# 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 操作更新的迁移,还是会尝试全部运行它们?

【问题讨论】:

  • 你没有想过简单地运行这几个命令来检查自己吗?
  • @MichaelSzyndel - 谁说我没想到?
  • 你的问题是这样的。如果你这样做了,你会发现它应该可以正常工作(只要在 schema:load 期间填充了迁移数据库表,我并没有真正检查过)

标签: ruby-on-rails database-migration rails-migrations


【解决方案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 表中,就好像它已经运行过一样,尽管它显然没有运行。)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-05-05
    • 1970-01-01
    • 2010-09-07
    • 2011-03-15
    • 2021-11-02
    • 1970-01-01
    • 1970-01-01
    • 2017-03-05
    相关资源
    最近更新 更多