Hibernar muitos para um HQL consulta, quando a propriedade interna de ingressos Fetch não está associada

Question

Eu tenho uma associação de muitos para um configurada assim, no 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>

E estou usando instrumentação para fazer um verdadeiro carregamento preguiçoso.

Mas quando eu executo uma consulta HQL com uma junção interna Fetch para a outra tabela, a propriedade que deve conter o objeto que é o valor da outra tabela é deixada como nula. Mesmo que eu possa ver o objeto do valor da outra tabela sendo criado por Hibernate.

Alguém tem alguma visão sobre esse problema?

atualizar:

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

Como você está usando instrumentação de código de bytes em vez de proxy de associação (por quê?), Você precisa especificar "buscar todas as propriedades" em sua consulta:

from Gig g fetch all properties ... 

Detalhes são aqui

Atualizar: Sua gigVenue O mapeamento está configurando lazy para no-proxy. O que isso significa é que a propriedade será nula até o seu primeiro método Getter. Isso é feito usando instrumentação de código de bytes e não é algo comumente usado. Usando HQL join fetch não preencherá essa propriedade; você tem que especificar explicitamente fetch all properties Como descrevi acima.

Considere definir lazy="proxy" em vez disso (esse é realmente o padrão para muitos para um) que inicializará sua propriedade com um objeto proxy contendo gigVenue Identificador durante a seleção inicial e recupere a entidade real depois de acessar um dos GigVenueMétodos. Usando join fetch no HQL também funcionará neste caso, buscando GigVenue instância durante a seleção inicial.

Naquela nota, configuração fetch="select" também é questionável; você provavelmente é melhor deixá -lo no padrão join Configuração para ativar o uso de junções externas para buscar.

Answer 2

A instrumentação não afeta realmente as consultas e como elas funcionam. Por que exatamente você está fazendo a busca na consulta? Você está tentando acelerar as coisas?

E também uma pequena pergunta, apenas para o caso, como você conhecer O valor é nulo? Isso é através do depurador Java ou é realmente chamando o método "Get"? Com a instrumentação, o campo normalmente será nulo, até você realmente pedir o campo.