Hibernate HQL-запрос многие-к-одному, когда свойство извлечения внутреннего соединения не связано - PullRequest
Новая
       11

Hibernate HQL-запрос многие-к-одному, когда свойство извлечения внутреннего соединения не связано

1 голос
/ 06 августа 2009

В 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>

И я использую контрольно-измерительные приборы для настоящей ленивой загрузки.

НО, когда я запускаю hql-запрос с внутренним извлечением соединения с другой таблицей, свойство, которое должно содержать объект, являющийся значением другой таблицы, остается равным нулю. Даже при том, что я могу видеть объект значения другой таблицы, созданный hibernate.

У кого-нибудь есть понимание этой проблемы?

Обновление: 

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>

Ответы [ 2 ]

1 голос
/ 06 августа 2009

Поскольку вы используете инструментарий байт-кода вместо прокси-сервера ассоциации (почему?), Вам нужно указать в запросе «извлечь все свойства»: 

from Gig g fetch all properties ...

Подробности здесь

Обновление: Ваше отображение gigVenue устанавливает lazy в no-proxy. Это означает, что свойство будет иметь значение NULL до его первого доступа через метод getter. Это делается с помощью инструментария байт-кода и не является тем, что обычно используется. Использование HQL join fetch НЕ заполняет такое свойство; Вы должны явно указать fetch all properties, как я описал выше.

Рассмотрите возможность установки lazy="proxy" вместо этого (это фактически значение по умолчанию для многих к одному), которое инициализирует ваше свойство с прокси-объектом, содержащим идентификатор gigVenue во время первоначального выбора, а затем извлекает фактическую сущность, как только вы получаете доступ к одному из GigVenue методы. Использование join fetch в HQL также будет работать в этом случае, извлекая полный экземпляр GigVenue во время первоначального выбора.

На этой ноте настройка fetch="select" также сомнительна; вам, скорее всего, лучше оставить значение по умолчанию join, чтобы разрешить использование внешних объединений для извлечения.

0 голосов
/ 06 августа 2009

Инструментарий на самом деле не влияет на запросы и то, как они работают. Почему именно вы делаете выборку в запросе? Вы пытаетесь ускорить процесс?

А также небольшой вопрос, на всякий случай, откуда вы знаете значение null? это через отладчик Java или это на самом деле вызов метода "get"? При использовании инструментов, поле обычно будет нулевым, пока вы на самом деле не спросите его.

...