Hi Marc, If you can't tell, this question is making me curious... What if you changed your query to be like this:
SELECT b FROM Box b JOIN FETCH b.order JOIN order o JOIN FETCH o.orderPositions WHERE b.id = ?1 I don't even know if this will be processed correctly or if it's "legal" per the spec, but on paper it looks good. :-) As I dug through our mail archives, I did see where the single level of fetching is clarified: http://openjpa.208410.n2.nabble.com/Problem-with-join-fetch-tc2958609.html So, the basic question you posted is not a bug. But, there are other ways of getting around the issue per the posting above. Another thing you may want to look at is the OpenJPA fetch groups. This would allow you to specify programatically when to lazy vs eager load a relationship, and how many levels to traverse. You can find more information on fetch groups here [1]. Specifically, take a look at section 7.3 on per-field fetch configuration. Good luck, Kevin [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_fetch On Tue, Feb 22, 2011 at 2:42 PM, Kevin Sutter <[email protected]> wrote: > I looked at our existing junit tests and it looks like we're testing a > single level of fetching. That is, if b <-> orders was 1:n instead of 1:1, > then you could do the "JOIN FETCH b.orders". It looks like we have tested > that processing. But, not going multiple levels... > > If I look at the spec (section 4.4.5.3), it states: > > *The syntax for a fetch join is* > > *fetch_join ::= [ LEFT [OUTER] | INNER ] JOIN FETCH > join_association_path_expression* > > *The association referenced by the right side of the FETCH JOIN clause > must be an association or element* > *collection that is referenced from an entity or embeddable that is > returned as a result of the query.* > > Since you result of this query is returning "b", and your JOIN FETCH is > attempting to access b.order.orderPositions, orderPositions are not directly > referenced by b. The spec is not clear on whether the additional levels of > traversal are expected. > > Any other insights from other readers? > > Kevin > > > On Tue, Feb 22, 2011 at 2:27 PM, Kevin Sutter <[email protected]> wrote: > >> Hmmm... It's my understanding that a JOIN FETCH should preload the >> relationship, even if it's marked as being Lazy. Have you performed a SQL >> trace to see if we're even attempting to load the relationship? Unless >> someone else speaks up, this would seem to be a bug. >> >> Kevin >> >> >> On Tue, Feb 22, 2011 at 12:08 PM, Marc Logemann <[email protected]> wrote: >> >>> Hi, >>> >>> assume this code: >>> >>> Query query = getEntityManager().createQuery("SELECT b FROM Box b >>> JOIN FETCH b.order.orderPositions WHERE b.id = ?1"); >>> query.setParameter(1, boxId); >>> List<Box> boxList = query.getResultList(); >>> >>> The relationship is: >>> >>> box <-- 1:1 ---> order <-- 1:n --> orderPositions >>> >>> When doing this query, i would expect that the orderPositions are >>> attached but they are null (order is attached to the box as expected but >>> thats 1:1) . I checked this right after the query.getResultList() call. >>> What am i missing here? >>> >>> thanks for infos. >>> >>> --- >>> regards >>> Marc Logemann >>> http://www.logemann.org >>> http://www.logentis.de >>> >>> >>> >>> >>> >> >
