loading Eager de entidades cargadas perezosos en NHibernate usando ActiveRecord

Question

Estoy trabajando en un proyecto que tiene un modelo de objetos enriquecido con varios conjuntos de raíces agregadas.

Estamos utilizando el Castillo pila (monorraíl a través de NHibernate con ActiveRecord).

Hemos marcado las raíces agregadas [ActiveRecord(Lazy = true)] como perezosos y hemos personalizado rutinas 'ansiosos' en nuestro repositorio de ganas ir a buscar un gráfico de objetos. Utilizamos HQL para definir recuperaciones ansiosos de nuestra colección infantil de nuestra raíz,

por ejemplo. Si Account es la raíz agregada (y marcamos cargado ligeramente) vamos a explorar más entidades ansiosos Account .. Order .. Product para un grafo completo.

Así que no hay sorpresas hasta el momento (con suerte).

Ahora bien, si en el ejemplo anterior, producto también está marcada [ActiveRecord(Lazy = true)], esto parece detener la directiva se ha podido recuperar ansiosos en el HQL.

¿Alguien sabe una manera de forzar la ansiosa FETCH sobre un objeto secundario cargado perezoso ??

Saludos Ian

Actualizar

Ok He aquí algunos ejemplo HQL, utilizando el ejemplo de 'me.yahoo.com/../1' a continuación, estamos usando IMuliQuery a reslove N + 1 dependencias se deben recuperar más de las relaciones muchos-a-muchos. También estamos utilizando explícitamente muchos-a-muchos clases de mapeo. Como resultado, nuestro HQL es:

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 = ?

... por lo que este ejecuta las sentencias SQL 2 y devuelve el conjunto de filas mínima requerida, y podemos resolver esto abajo en un solo gráfico de objetos. Niza.

Pero ... si, por ejemplo, Address fue marcado cargado ligeramente (y no era Order), el acceso a Order no desencadena un sentencias SQL más, sin embargo, el acceso a Address no, a pesar del hecho de que ambos son ansiosos cargado.

Así que por qué no es la entidad cargada perezoso Address, arriba, ansiosos por descabellada la afirmación anterior?

Answer 1

¿Por qué quiere el comportamiento ansioso?

Todos los atributos en la relación de ActiveRecord tienen un parámetro de 'Lazy =' para contar ActiveRecord a la carga perezosa del objeto relacionado. Todos excepto Pertenece. Pertenece comprueba si el objeto dependiente tiene Lazy = true en su atributo ActiveRecord y luego crea un proxy para el objeto en lugar de hacer una selección o unirse.

Para Lazy carga de trabajo Todos los métodos y propiedades de la instancia de clase que han de caracterizarse como virtual. Esto permite ActiveRecord para la construcción de una clase de proxy dinámico.

Ahora que puede sonar como una buena idea para buscar el gráfico completo para el rendimiento pero en la práctica es probablemente más lento. Tengo 3 buenas razones por las que:

1.) Pertenece tiene una opción de Fetch para definir cómo los objetos relacionados se retiró. fuerzas FetchEnum.Join AR utilizar una combinación. FetchEnum. Seleccione fuerzas AR utilizar sentencias de selección independientes para cada objeto. Se une son lentos, se observa una mejora 10x rendimiento del cambio a individuo selecciona. No hay una diferencia efectiva en el código cliente entre Lazy = true + FetchEnum.Select y con ganas.

2.) NHibernate hace almacenamiento en caché. Si el objeto ya se almacena en caché en la sesión o en el caché de nivel 2 que puede ser cargado forma allí y evitar el trabajo extra.

3.) Se podría perder la oportunidad de los beneficios de la carga diferida en los casos donde no referencias de las piezas del gráfico de objetos. Una vez más usted haría más trabajo de lo necesario.

Answer 2

do "combinación interna ir a buscar" una sobre la entidad Account.Order.Product. Así que en lugar de algo como esto (que es lo que probablemente ya tiene):

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

Díselo a buscar a la Order.Product así:

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

Answer 3

De "NHibernate en Acción", página 225:

  

NHibernate actualmente se limita a ir a buscar sólo una colección con impaciencia.

Eso podría explicar la segunda consulta para ir a buscar las direcciones.