# GH 工作流测试中出现奇怪的迁移错误

**URL:** <https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022>\
**Category:** Development\
**Created:** [2023年十一月29日 23:18 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022 "2023-11-29T23:18:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2023年十一月29日 23:18 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022/1 "2023-11-29T23:18:11Z")

</div>

我正在尝试创建一个与 Topics 表的外键关系。

问题是，在 GitHub 工作流测试环境中，测试因奇怪的原因而失败，它试图访问父表中一个早已不存在且在几年前的核心迁移中已被删除的字段！

错误是 `PG::UndefinedColumn: ERROR: column topics.off_topic_count does not exist`

是的，[因为它在 2018 年的核心迁移中被删除了](https://github.com/discourse/discourse/blob/e30678ae14a91cf591a383ebccaef958b7a25d7a/db/migrate/20180917024729_remove_superfluous_columns.rb#L21)！

我已确认这在测试过程中已经运行：

```plaintext
== 20180917024729 RemoveSuperfluousColumns: migrating =========================
== 20180917024729 RemoveSuperfluousColumns: migrated (0.0410s) ===============

```

我并没有以任何方式显式引用这个旧的父表字段……它似乎在自己生成 SQL……但对于当前的事物定义来说是不恰当的。

```plaintext
== 20231119010101 CreateLocationsTopicTable: migrating ========================rake aborted!

[12035](https://github.com/paviliondev/discourse-locations/actions/runs/7039607316/job/19158951878?pr=103#step:19:12036)StandardError: An error has occurred, this and all later migrations canceled: (StandardError)

[12036](https://github.com/paviliondev/discourse-locations/actions/runs/7039607316/job/19158951878?pr=103#step:19:12037)

[12037](https://github.com/paviliondev/discourse-locations/actions/runs/7039607316/job/19158951878?pr=103#step:19:12038)PG::UndefinedColumn: ERROR: column topics.off_topic_count does not exist

[12038](https://github.com/paviliondev/discourse-locations/actions/runs/7039607316/job/19158951878?pr=103#step:19:12039)LINE 1: ...cs"."deleted_at", "topics"."highest_post_number", "topics"...

```

表定义非常简单：

```plaintext
class CreateLocationsTopicTable < ActiveRecord::Migration[7.0]
  def change
    create_table :locations_topic do |t|
      t.references :topic, foreign_key: true
      t.float :latitude, null: false

SNIP

```

更奇怪的是，这个迁移在 Production 中是有效的！

欢迎任何见解！

---

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2023年十一月29日 23:48 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022/2 "2023-11-29T23:48:33Z")

</div>

我因为这个 👮 🚓 被 RUBOCOPPED 了。

```plaintext
Offenses:

db/migrate/20231119010101_create_locations_topic_table.rb:6:7: C: Discourse/NoAddReferenceOrAliasesActiveRecordMigration: AR 方法 add_reference、add_belongs_to、t.references 和 t.belongs_to 对于大表来说风险很高，并且有太多的后台魔法操作。
请改用 disable_ddl_transactions! 迁移并编写自定义 SQL 来添加新列和 CREATE INDEX CONCURRENTLY。使用 IF NOT EXISTS 子句使迁移在部分失败后可以重新运行。

      t.references :topic, foreign_key: true
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

```

现在，这 _可能_ 是问题的一部分。

太多的 🪄 在起作用，这就是问题所在！

活到老，学到老！ 🎓

---

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\
**Post date:** [2023年十一月30日 00:03 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022/3 "2023-11-30T00:03:59Z")

</div>

Rubocop 的建议是好的，但我认为它不是导致此错误的原因。（它提到的“风险”是指对高流量表的锁定，这会影响生产流量。因此，这不会在测试环境中导致错误）

您可以通过执行 `RAILS_ENV=test bin/rake db:drop db:create db:migrate`（即从头开始迁移数据库，并启用 locations 插件）在本地重现相同的错误。

我怀疑问题在于您[在迁移中调用 Rake 任务](https://github.com/paviliondev/discourse-locations/blob/2c5fe46038326c72ae7160d9d6d204080980ebb4/db/migrate/20231128010101_populate_locations_tables.rb#L4-L5)。在核心代码中，我们通常避免在迁移中运行任何类型的应用程序代码，因为这可能会产生奇怪的副作用。最好坚持使用纯 SQL。

在这种情况下，我的假设是 ActiveRecord 模式缓存会在迁移早期被填充（当 `topics.off_topic_count` 仍然存在时）。然后，当您的 rake 任务运行时，它将使用旧的模式缓存运行，因此 ActiveRecord 会尝试加载已不存在的列。

您可以通过在调用 rake 任务之前添加 `ActiveRecord::Base.clear_cache!` 来缓解此问题……但不要将其视为建议 😉。最好的办法是完全避免调用 rake 任务。如果您需要在数据库中操作某些内容，请在迁移中使用纯 SQL。

---

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2023年十一月30日 00:11 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022/4 "2023-11-30T00:11:40Z")

</div>

谢谢你，大卫，我会把它移到一个 SQL 语句，看看是否能解决……

---

<div class="post-metadata">

**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
**Post date:** [2023年十二月1日 15:08 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022/5 "2023-12-01T15:08:31Z")

</div>

太好了，谢谢 David！

> <https://github.com/merefield/discourse-locations/pull/103/commits/296a890791f6507d35045afbbef7c4e1e98befdf>

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)\
**Post date:** [2023年十二月31日 15:09 UTC](https://meta.discourse.org/t/strange-migration-error-in-tests-during-gh-workflow/287022/6 "2023-12-31T15:09:05Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.