eager loading di entità caricati pigri in NHibernate usando ActiveRecord

Question

Sto lavorando su un progetto che ha un modello di oggetti ricchi di vari set di radici di aggregazione.

Stiamo usando il Castello di stack (monorotaia fino alla NHibernate con ActiveRecord).

Abbiamo segnato le radici di aggregazione [ActiveRecord(Lazy = true)] come pigri e abbiamo personalizzato routine 'ansiosi' sul nostro repository per ansioso prendere un oggetto grafico. Usiamo HQL per definire recupera desiderosi dalla nostra collezione figlio della nostra radice,

es. se Account è la radice di aggregazione (e segnato caricato in modo pigro) saremo ansiosi recuperiamo entità Account .. Order .. Product per un grafico completo.

Quindi nessuna sorpresa finora (si spera).

Ora, se nel precedente esempio, il prodotto è anche segnato [ActiveRecord(Lazy = true)], questo sembra fermare la voglia prendere direttiva nel HQL.

Qualcuno sa un modo per forzare la desideroso fetch un oggetto pigro bambino caricato ??

Saluti ian

Aggiorna :

Ok Ecco qualche esempio HQL, Utilizzando l'esempio da 'me.yahoo.com/../1' al di sotto, stiamo usando IMuliQuery a reslove N + 1 dipendenze quando va a prendere nel corso di molti-a-molti. Stiamo anche in modo esplicito utilizzando molti-a-molti classi di mappatura. Di conseguenza la nostra HQL è:

from Account a 'm eager loading the graph
inner join fetch a.AccountsOrders ao 
inner join fetch ao.Order
from Account a 'm eager loading the graph
inner join fetch a.AccountAddresses aa
inner join fetch aa.Address ad
where a.ID = ?

... quindi questo esegue le istruzioni 2 SQL e restituisce il set di righe minima richiesta, e siamo in grado di risolvere questo verso il basso in un singolo oggetto grafico. Nizza.

Ma ... se, per esempio, è stato caratterizzato Address caricato in modo pigro (e Order non era), l'accesso Order non fa scattare un ulteriore istruzioni SQL, ma l'accesso ai Address fa, nonostante il fatto entrambi sono desiderosi caricato.

Quindi, perché non è il pigro caricato entità Address, soprattutto, desideroso inverosimile dalla dichiarazione di cui sopra?

Answer 1

Perché vuoi il comportamento ansioso?

Tutto il rapporto attributi in ActiveRecord hanno un parametro 'Pigro =' dire ActiveRecord a carico pigro il relativo oggetto. Tutti tranne Pertinenti. Pertinenti verifica se l'oggetto dipendente ha pigro = true nel suo attributo ActiveRecord e quindi crea un proxy per l'oggetto invece di fare una selezione o unirsi.

Per Pigro caricamento funzioni tutti i metodi e le proprietà dell'istanza classe devono essere contrassegnati come virtuale. Questo permette ActiveRecord di costruire una classe proxy dinamica.

Ora, può sembrare una buona idea per andare a prendere il grafico completo per le prestazioni, ma, in pratica, la sua, probabilmente più lenta. Ho 3 buone ragioni per cui:

1.) Pertinenti ha una Fetch opzione per definire come gli oggetti correlati sono tirato. forze FetchEnum.Join AR di utilizzare un join. FetchEnum. Selezionare le forze AR di utilizzare le istruzioni SELECT separati per ogni oggetto. Unisce sono lenti, vediamo un miglioramento delle prestazioni 10x di passare a individuo seleziona. Non c'è differenza efficace nel codice client tra pigro = true + FetchEnum.Select e desiderosi.

2.) NHibernate fa il caching. Se l'oggetto è già memorizzato nella cache nella sessione o nella cache di livello 2 può essere caricata forma lì ed evitare il lavoro supplementare.

3.) Si potrebbe perdere i benefici di lazy loading nei casi in cui non hai riferimento parte del grafico dell'oggetto. Anche in questo caso si dovrebbe fare più lavoro di quanto necessario.

Answer 2

fare un "inner join fetch" sull'entità Account.Order.Product. Così, invece di qualcosa come questo (che è ciò che probabilmente avete già):

"from Account a inner join fetch a.Order where a.ID = ?"

Dillo a prendere l'Order.Product così:

"from Account a inner join fetch a.Order inner join fetch a.Order.Product where a.ID = ?"

Answer 3

Da "NHibernate in azione", pagina 225:

  

NHibernate attualmente si limita a recupero solo una raccolta con entusiasmo.

Questo potrebbe spiegare la seconda query per il recupero degli indirizzi.