Rails 4.2：带作用域的关联delete_all为何与直接调用行为不同？

我来帮你拆解这个问题——这其实是Rails关联查询在作用域过滤后返回对象类型变化导致的典型问题。

先把你的模型代码整理清晰：

class Option < ActiveRecord::Base
  has_many :item_options
  has_many :items, through: :item_options, source: :item
  
  scope :materials, -> { where(category: 'material') }
  scope :types, -> { where(category: 'type') }
end

class Item < ActiveRecord::Base
  has_many :item_options
  has_many :options, through: :item_options
end

核心差异的原因 #

当你调用 Item.first.options.delete_all 时，你操作的是Rails专属的关联集合对象（ActiveRecord::Associations::CollectionProxy）。这个对象清楚自己是Item和Option之间的through关联，所以delete_all会自动定位到中间的item_options联结表，只删除关联关系，不会触碰Option本身的记录。

但当你加上作用域 Item.first.options.materials.delete_all 时，调用materials作用域后，返回的不再是关联集合对象，而是一个普通的ActiveRecord查询集合（ActiveRecord::Relation）。这个查询集合只知道自己是Option模型的查询结果，完全忽略了原来的关联上下文，所以delete_all会直接删除这些Option记录，这就不符合你的预期了。

快速验证方式 #

你可以在控制台里打印两个对象的类型，一眼就能看出区别：

# 输出 ActiveRecord::Associations::CollectionProxy::HasManyThrough
puts Item.first.options.class

# 输出 ActiveRecord::Relation
puts Item.first.options.materials.class

解决方法 #

如果你想通过作用域过滤后只删除对应的关联关系（不碰Option记录），可以换两种写法：

• 方法1：直接操作中间表（性能最优）
  绕过关联集合，直接定位到item_options表并过滤条件：

  Item.first.item_options.joins(:option).where(options: { category: 'material' }).delete_all
  

• 方法2：使用destroy_all（会触发回调）
  虽然destroy_all会先加载匹配的Option对象再逐个删除关联，但能触发模型回调，适合需要业务逻辑校验的场景：

  Item.first.options.materials.destroy_all
  

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