comportamento imprevisto con ActiveRecord comprende

Question

che sto utilizzando il metodo AR includes per eseguire un join esterno sinistro tra gli oggetti utente e costruzione, dove un utente può o non può avere un'associazione di costruzione:

users = User.includes(:building).references(:buildings) 

Dato che sto usando references, qualsiasi oggetto Building associato sarà caricato con entusiasmo.

La mia aspettativa era che sarei stato in grado di scorrere l'elenco degli utenti e controllare se un utente aveva un edificio associato con loro senza attivare query aggiuntive, ma vedo che in effetti ogni volta che provo ad accedere all'edificio proprietà di un utente che non ne ha uno, AR effettua un'altra chiamata SQL per provare a recuperare tale edificio (anche se nei tentativi successivi restituirà solo zero).

Queste query sono ovviamente ridondanti in quanto l'associazione sarebbe stata caricata durante il join iniziale e sembra vanificare l'intero scopo del caricamento ansioso con include/riferimenti, poiché ora sto osservando N volte il numero di query uguali al numero di associazioni vuote.

users.each do | user | 

    # This will trigger a new query when building is not present: 
    # SELECT "buildings".* FROM "buildings" WHERE "buildings"."address" = $1 LIMIT 1 [["address", "123 my street"]] 
    if user.building 
    puts 'User has building' 
    else 
    puts 'User has no building' 
    end 

end 

classe User:

class User < ActiveRecord::Base 
    belongs_to :building, foreign_key: 'residence_id' 
end 

C'è un modo per verificare la presenza di un'associazione costruzione degli utenti senza innescare query in più?

---

On Rails 4.2.0/POSTGRES

---

UPDATE:

Grazie @BoraMa per mettere insieme questo test. Sembra che stiamo ottenendo un comportamento differente tra le versioni Rotaie recenti:

USCITA (rotaie 4.2.0):

User 1 has building 
User 2 has building 
User 3 has no building 
D, [2016-05-26T11:48:38.147316 #11910] DEBUG -- : Building Load (0.2ms) SELECT "buildings".* FROM "buildings" WHERE "buildings"."id" = $1 LIMIT 1 [["id", 123]] 
User 4 has no building 

USCITA (rotaie 4.2.6)

User 1 has building 
User 2 has building 
User 3 has no building 
User 4 has no building 

USCITA (rotaie 5.0 .0)

User 1 has building 
User 2 has building 
User 3 has no building 
User 4 has no building 

rosticcerie:

• Questo problema è stato limitato a "penzolanti chiavi esterne (cioè la colonna residence_id non è nullo, ma non corrisponde alcun oggetto edificio)" (Grazie @FrederickCheung)
• Il problema è stato risolto alla Rails 4.2. 6

Answer 1

Suona come hai morso da un bug in Active Record, che è stato fissato in Rails 4.2.3.

Nel caso in cui la colonna fosse nil, Active Record sa già che non è nemmeno necessario provare a caricare l'oggetto associato. I casi rimanenti sono stati quelli interessati da questo errore

Answer 2

sembra un errore di battitura, si prega di notare building invece di buildings: User.includes(:building).references(:buildings)

Questo dovrebbe far scattare il grande query che utilizza il formato di AS tX_rY per ogni associazione e tabl e.

Answer 3

Sembra che dal binario 4.1 ci siano potenziali scontri con il modo in cui dovrebbero essere inclusi gli #inclusi impliciti, vedere il seguente open issue.

Questo codice è tutto testato per la sintassi, ma ci sarebbero due approcci vorrei provare:

1/rendono il eager loading implicita

users = User.eager_load(:building).preload(:buildings) 

2/separare i due tipi di utenti, quelli in cui l'edificio è collegato, il che significa che non provi nemmeno a precaricare l'edificio, rimuovendo l'inefficienza.

users = User.includes(:building).where.not(residence_id: nil).references(:buildings) 

users.each do | user| 
    puts "User has building: #{user} #{user.building}" 
end 

# No additional references needed to be eager-loaded. 
users = User.where(residence_id: nil) 
users.each do | user | 
    puts "#{User} has no building." 
end