Rails关联块方法疑问：子查询来源、self指向及重构建议

模型与关联关系 #

user.rb #

class User < ApplicationRecord
  validates :name, presence: true

  has_many :posts
  has_many :favorites
  has_many :favorite_posts, through: :favorites, source: :post do
    def by_other_user
        where(user: self)
    end
  end
end

favorite.rb #

class Favorite < ApplicationRecord
  belongs_to :user
  belongs_to :post
end

post.rb #

class Post < ApplicationRecord
  belongs_to :user
end

原查询问题分析 #

执行User.find(1).favorite_posts.by_other_user时，生成的数据库查询如下：

SELECT "posts".* FROM "posts" 
INNER JOIN "favorites" ON "posts"."id" = "favorites"."post_id"
WHERE "favorites"."user_id" = 1 
AND "posts"."user_id" IN (
    SELECT "posts"."id" FROM "posts" INNER JOIN "favorites" ON "posts"."id" = "favorites"."post_id" WHERE "favorites"."user_id" = 1
)

子查询来源与self指向问题 #

1. 子查询的来源：by_other_user方法中的where(user: self)是问题根源。这里的self并非预期的id=1的User对象，而是favorite_posts关联返回的Post对象集合（ActiveRecord::Relation）。当把一个Relation传入where(user: ...)时，Rails会自动将其转换为子查询，试图让posts.user_id匹配子查询返回的posts.id，最终生成了多余的IN子查询。

2. self指向Post集合的原因：by_other_user定义在favorite_posts关联的扩展块内，这个块中的方法作用于关联返回的Post查询集合，因此方法内部的self指向该Post的Relation，而非调用关联的User对象。

重构代码反馈 #

你重构后的代码如下：

has_many :favorite_posts, -> { distinct }, through: :favorites, source: :post

def favorite_posts_by_someone_else
  favorite_posts.includes(:user).where.not(posts: { user: self })
end

对应的查询为：

SELECT "posts".* FROM "posts" INNER JOIN "favorites" ON "posts"."id" = "favorites"."post_id"
WHERE "favorites"."user_id" = 1 
AND "posts"."user_id" != 1

重构的优势： #

• 逻辑拆分合理：将关联定义与业务方法分离，favorite_posts专注于关联本身，distinct避免重复数据（即使单用户不会重复收藏同一帖子，加上也能提升鲁棒性）；favorite_posts_by_someone_else作为实例方法，内部self明确指向当前User对象，能精准筛选出非当前用户发布的收藏帖子。
• 查询性能更优：原查询用子查询实现过滤，重构后直接通过posts.user_id != 1筛选，避免了不必要的嵌套查询，执行效率更高。
• 可读性更强：方法名favorite_posts_by_someone_else清晰表达业务意图，比原by_other_user更直观易懂。

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