2011-07-08 10 views
6

Po uaktualnieniu do wersji nowszej hibernacji (domyślam się, że przyszedł z przełącznikiem z JBoss 4.2.2 na JBoss 6), niektóre pytania nie z komunikatem:„Automatic” join pobierania podmiotów zagnieżdżonych nie po aktualizacji Hibernate

Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: query specified join fetching, but the owner of the fetched association was not present in the select list [FromElement{explicit,not a collection join,fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName= (...)

ma to miejsce zawsze w przypadku zastosowania zapytanie tak:

SELECT entityA FROM EntityA entityA 
JOIN FETCH entityA.entityB 
LEFT JOIN FETCH entityA.entityB.someField 
WHERE entityA.entityB.anotherField LIKE :someParameter 

rozwiązaniem tego problemu jest zapewnienie „entityA.entityB” alias, a następnie użycie tego skrótu w klauzuli WHERE. Ale w niektórych zapytaniach nie jest jednoznacznie podana LEFT JOIN FETCH, ale nadal klauzula WHERE wykorzystuje właściwość odwołanej jednostki. Czy tam też się nie uda? Co się zmieniło, tak że nagle przestaje działać po przejściu na nową wersję JBoss?

Następujące question jest związane z tym pytaniem i zawiera rozwiązanie, ale nie wyjaśnia problemu.

+0

Twoje pytanie pomogło mi znaleźć rozwiązanie mojego problemu, po aktualizacji z wersji 3.2.6.ga do wersji 3.5.6 otrzymałem "zapytanie o dołączenie pobierania", ale właściciel pobranego skojarzenia nie był obecny na liście wyboru ", używając podejścia aliasowego, które zasugerowałeś, że działa, nie może ci pomóc z" dlaczego "! –

+0

jest tym HQL lub standardowym JPQL? – wrschneider

+0

Wykonuje się to za pomocą 'EntityManager.createQuery', więc domyślam się, że to HQL. –

Odpowiedz

3

Kwerenda powinna być

SELECT entityA FROM EntityA entityA 
JOIN FETCH entityA.entityB entityB 
LEFT JOIN FETCH entityB.someField 
WHERE entityB.anotherField LIKE :someParameter 

Tj należy przypisać alias do każdej dołączonej jednostki i użyć tego aliasu dla kolejnych sprzężeń lub ograniczeń.

+0

Tak, wiem ... ale zawsze tak było. A przejście z Hibernate 3 na 4 zmieniło w pewien sposób akceptację, a to powoduje, że wiele migracji działa dla nas. Właśnie chciałem wiedzieć dlaczego oni nagle przestali robić Hibernując kompatybilny wstecz w krótkim czasie. –

+0

Domyślam się, że twój kod działał przez przypadek, opierając się na błędu Hibernacji, który został naprawiony teraz. –

0

Mam ten sam problem w moim projekcie i jest to bardzo trudne do rozwiązania, ponieważ mam duży, starszy system z wieloma modułami, które używają wstępnie skompilowanych nazwanych zapytań i wielu zapytań tworzonych na żądanie. Identyfikacja i modyfikacja całego systemu oraz wprowadzanie zmian tam, gdzie działało również przy użyciu starej wersji hibernacji, jest bardzo denerwująca i podatna na błędy. Przechodzę przez ten problem w JBoss od 6.4 do 6.4.6, gdy wersja hibernacji została uaktualniona z 4.2.18 do 4.2.22 i pojawia się ten błąd. Aby go rozwiązać, dokonuję downgrade tylko głównego modułu hibernacji do początkowej domyślnej wersji 4.2.18, ale to nie jest dobre, ponieważ kiedy pojawia się kolejna łata JBoss, muszę ją zmienić. Próbuję użyć modułów JBoss i niektórych konfiguracji w persistence.xml i jboss-deployment-strcuture.xml, ale bez powodzenia.