Rails 4.2 STI中间子类首次查询失败后续查询正常问题

我之前也踩过这个STI的坑，刚好能帮你理清问题根源和解决办法！

问题复现 #

你遇到的是典型的Rails STI延迟加载导致的异常：

• 继承链：KbtPrimary < KbTagged < Keybox
• 首次用中间类KbTagged查询时，SQL仅筛选type = 'KbTagged'的记录，找不到实际属于KbtPrimary类型的目标数据
• 但只要用父类Keybox或者子类KbtPrimary查询过一次，后续再用KbTagged查询，SQL就会自动包含type IN ('KbTagged', 'KbtPrimary')，就能正常命中数据

从你提供的SQL对比能一眼看出差异：
首次查询KbTagged的SQL：

SELECT "keyboxes".* FROM "keyboxes" WHERE "keyboxes"."type" IN ('KbTagged') AND "keyboxes"."company_id" = 2 AND "keyboxes"."name" = 'Automated'

查询过父类后，再次查询KbTagged的SQL：

SELECT "keyboxes".* FROM "keyboxes" WHERE "keyboxes"."type" IN ('KbTagged', 'KbtPrimary') AND "keyboxes"."company_id" = 2 AND "keyboxes"."name" = 'Automated'

原因分析 #

Rails为了优化启动和加载性能，默认会延迟加载STI子类——也就是说，在你没有显式引用某个子类之前，Rails不知道它的存在。所以首次查询中间类KbTagged时，Rails默认认为它没有子类，只会筛选自身的type值；而当你查询过KbtPrimary或者父类Keybox（父类查询会触发所有子类的加载），Rails就会把KbtPrimary加入到KbTagged的子类集合中，后续查询就会自动包含这些子类的type。

解决方案 #

有几种可靠的方法可以彻底解决这个问题：

1. 在中间类中提前加载子类

在KbTagged模型中添加require_dependency，强制Rails加载它的子类：

class KbTagged < Keybox
  # 提前加载子类，确保Rails初始化时就知道KbtPrimary的存在
  require_dependency 'kbt_primary'
end

这种方法针对性强，只加载需要的子类，适合明确知道子类名称的场景。

2. 全局预加载所有STI子类

如果你的STI子类比较多，或者后续可能新增子类，可以在初始化文件里批量加载：
新建config/initializers/sti_loader.rb，添加以下代码：

# 预加载Keybox的所有STI子类（假设子类命名都以kb开头，可根据实际调整匹配规则）
Dir[Rails.root.join('app/models/kb*.rb')].each do |file|
  require_dependency file
end

这样Rails启动时就会加载所有相关子类，从根源避免延迟加载带来的问题。

3. 手动触发子类加载（适合开发调试）

在KbTagged模型中调用descendants方法，触发子类加载：

class KbTagged < Keybox
  # 触发子类加载，确保首次查询时包含所有子类
  descendants
end

不过这种方法在开发环境可能因为代码热重载失效，生产环境稳定可用，更适合临时调试用。

验证效果 #

添加上述任意一种方法后，首次查询KbTagged时，生成的SQL就会自动包含KbtPrimary的type值，直接就能找到目标记录，不需要先查父类或者子类做"预热"了。

内容的提问来源于stack exchange，提问作者Richard_G