hibernar muchos-a-uno consulta HQL, cuando combinación interna se ha podido recuperar la propiedad no asociado

Question

Tengo una asociación muchos-a-uno configurado de esta manera, en el hbm.xml:

<many-to-one name="gigVenue"
class="blah.blah.xxx" fetch="select"
lazy="no-proxy" not-null="true" >
<column name="N_VENUE_ID" precision="18" scale="0" not-null="true" />
</many-to-one>

Y yo estoy usando la instrumentación de hacer verdadera carga diferida.

Pero cuando lo ejecuta una consulta HQL con una combinación interna ir a buscar a la otra tabla, la propiedad que debe contener el objeto que es el valor de la otra mesa, se deja como nulo. Aunque puedo ver objetos de valor de la otra tabla que se creó por Hibernate.

¿Alguien tiene alguna idea de este problema?

Actualización:

from Gig g inner join fetch g.gigVenue gv where g.artistId = :artistId and  (g.territoryId = -1 or g.territoryId = :territoryId) order by g.gigDatetime desc

<set name="gigs" inverse="true" lazy="true" table="DSP_GIG" fetch="select">
<key>
<column name="N_VENUE_ID" precision="18" scale="0" not-null="true" />
</key>
<one-to-many class="blah.blah.Gig" />
</set>

Answer 1

Dado que está utilizando instrumentación de código byte en lugar de proxy asociación (¿por qué?) Es necesario especificar "captar todas las propiedades" en su consulta:

from Gig g fetch all properties ... 

aquí

Actualización: Su asignación gigVenue está fijando lazy a no-proxy. Lo que esto significa es que la propiedad será NULL hasta su primera acceder a través de método getter. Esto se hace utilizando el código de bytes de instrumentación y no es algo que se utiliza comúnmente. Utilizando HQL join fetch no va a llenar este tipo de propiedad; usted tiene que especificar explícitamente fetch all properties como he descrito anteriormente.

Considere establecer lazy="proxy" lugar (que en realidad es el valor predeterminado para muchos-a-uno) que inicializar su propiedad con un objeto proxy que contiene identificador gigVenue durante el selecto inicial, a continuación, recuperar la entidad real, una vez se accede a uno de los métodos de GigVenue. Usando join fetch en HQL también trabajará en este caso, ir a buscar instancia GigVenue completo durante el selecto inicial.

En ese sentido, el establecimiento de fetch="select" también es cuestionable; lo más probable es mejor dejar en la configuración por defecto join para permitir el uso de las combinaciones externas de ir a buscar.

Answer 2

Instrumentación no afecta realmente a las consultas y cómo funcionan. ¿Por qué estás haciendo exactamente la pelota en la consulta? ¿Estás tratando de acelerar las cosas?

Y también una pequeña pregunta, por si acaso, ¿cómo sé el valor es nulo? es que a través del depurador Java o es que por el hecho de llamar al método "get"? Con la instrumentación, el campo será típicamente nula, hasta que realmente solicita el campo.