Início / coding / Perguntas / 79433738
Accepted
elabmot
Asked: 2025-02-13 00:10:49 +0800 CST

Qual é a diferença entre `joins` e `references` no Rails?

  • 772

Qual é a diferença entre isso:

User.includes(:sites).where("sites.name = 'test'").references(:sites)

e isto:

User.joins(:sites).where(sites: { name: "test"} )

Existe um consenso geral sobre o uso de um método em vez do outro?

ruby-on-rails

1 respostas

  1. Best Answer

    Eles fazem coisas completamente diferentes.

    .joins(:sites)adiciona um INNER JOINà relação que limita os resultados a usuários com pelo menos um site antes da cláusula where ser aplicada.

    Nenhuma coluna da tabela unida será selecionada (a menos que você faça isso manualmente). Use-o quando quiser apenas filtrar os resultados com uma junção, mas não se importar com os dados na tabela relacionada ou com .selecta seleção de agregados.

    Não impede consultas N+1 quando você acessa a associação:

    users = User.joins(:sites).where(sites: { name: "test" } )
# SELECT "users".* 
# FROM "users" 
# INNER JOIN "sites" 
#   ON "sites"."user_id" = "users"."id" 
# WHERE "sites"."name" = 'test'

users.each do |user|
  user.sites.each do |site|
    puts site.name # creates an additional database query for every site
  end
end

    .includesevita consultas N+1 de forma "inteligente". É extremamente usado em excesso e geralmente é melhor pensar em como você quer usar os dados e usar os métodos aos quais ele delega diretamente.

    Ele tentará usar .preloadpara fazer duas consultas onde a primeira selecionaria os dados da tabela de usuários e a segunda consulta selecionaria os dados das sitestabelas quando a associação for acessada pela primeira vez em qualquer membro da coleção. Isso evitará carregar os dados a menos que sejam realmente usados, ao mesmo tempo em que impede uma consulta N+1 para cada membro da associação.

    users = User.includes(:sites) # SELECT "users".* FROM "users" 
users.each do |user|
  user.sites.each do |site|
    puts site.name # only one additional database to fetch the sites is fired
  end
end

    No entanto, se a consulta fizer referência à tabela de sites por meio da cláusula where, .preloadisso não funcionará, pois não está unindo nada. .includesNa verdade, é inteligente o suficiente para detectar isso na maioria dos casos e usará .eager_loadpara carregar tudo em uma única consulta com uma junção externa.

    .referencesdiz explicitamente .includespara usar .eager_loade nesse exemplo evitará um driver de banco de dados que ocorre quando a consulta não se junta sites.

    User.includes(:sites).where("sites.name = 'test'")
#  User Load (0.8ms)  SELECT "users".* FROM "users" WHERE (sites.name = 'test') /* loading for pp */ LIMIT 11 /*application='Sandbox8'*/
# An error occurred when inspecting the object: #<ActiveRecord::StatementInvalid:"SQLite3::SQLException: no such column: sites.name:\nSELECT \"users\".* FROM \"users\" WHERE (sites.name = 'test') /* loading for pp */ LIMIT 11 /*application='Sandbox8'*/\n

    Mas se você apenas passar um hash .whereem vez de sabotá-lo ativamente com uma string SQL para fins de exemplo, ele funciona perfeitamente:

    User.includes(:sites).where(sites: { name: "test" })

    É ainda mais inútil se você considerar que você poderia simplesmente cortar o intermediário em vez de ser tão indeciso.

    # This runs just fine
User.eager_load(:sites).where("sites.name = 'test'")

# But this is preferable
User.eager_load(:sites).where(sites: { name: "test" })

    Acho que .referencesainda poderia preencher uma função de nicho se você estiver construindo uma consulta programaticamente e quiser usar a natureza de carregamento lento, .includesmas ao mesmo tempo evitar um erro de referência (esse cenário exigiu muita imaginação). Mas, em geral - YAGNI.

    • 3

relate perguntas