openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Simons <>
Subject Re: How work around OpenJPA-1365
Date Tue, 17 Nov 2009 17:02:38 GMT
Hi Mike,

Do you mean fetchplan like described in the manual in chapter 1.7.4?
Or is there a possibility to use JDO-FetchPlan with OpenJPA? If so, is there a description,
to do that?

kind regards,

Michael Dick schrieb:
> Hi all,
> Daryl's correct, the duplicates returned by a JOIN FETCH clause are correct
> behavior. If you don't want the duplicates to be returned you should use the
> DISTINCT keyword and OpenJPA will remove duplicates from the list.
> There are several outstanding issues though (which I'm working on):
> 1.) OPENJPA-894:  When results are returned from the database OpenJPA
> automatically removes duplicates from the list. If the results are fetched
> from memory the duplicates reappear.
> 2.) OPENJPA-1365: After you apply the fix for OPENJPA-894 the distinct
> keyword doesn't work. This is because OpenJPA merely prepends the DISTINCT
> keyword to the SQL generated which doesn't work if you're selecting across
> multiple tables. Instead we need to filter the result list after retrieving
> from the database.
> There are two proposed fixes for OPENJPA-894 each of which have some
> drawbacks.
> 3a.) Mike's fix : supports pagination but does not support multiple JOIN
> FETCH statements (ie SELECT m FROM Manager m JOIN FETCH m.employees JOIN
> FETCH m.projects returns the wrong number of results).
> 3b.) Fay's fix : supported multiple JOIN FETCH statements, but does not
> support pagination (ie query.setMaxResults(), query.setFirstResult() doesn't
> page forward as expected).
> So there is work being done, but it's turned out to be a very ticklish issue
> to solve.
> At the risk of muddying the waters a bit if you're migrating a JDO
> application have you considered using OpenJPA's FetchPlan implementation to
> eagerly load some fields? Over medium - large datasets I've found this to be
> significantly faster than using a JOIN FETCH, but YMMV.
> Hope this helps,
> -mike
> On Tue, Nov 17, 2009 at 8:48 AM, Daryl Stultz <> wrote:
>> On Tue, Nov 17, 2009 at 9:27 AM, Michael Simons
>> <>wrote:
>>> You state, that you're query with distinct and join fetch does work
>>> properly. But this would
>>> mean OpenJPA-1365 doesn't occur, does it?
>> The JIRA states:
>> This issue occurs if the proposed fix for OPENJPA-894 is in place.
>> So 1365 does not occur unless you've patched your code such that 894 is
>> fixed. What version of OpenJPA are you using and do you have any patches in
>> place?
>>> When we call "select a from A a join fetch B" we get n instances of A,
>> with
>>> n = numbers of
>>> A-B-associations.
>> This is the correct behavior. I have found with OpenJPA 1.2.1, I get
>> distinct rows of A which sounds like what you (and I) want but is improper.
>> 894 shows that a second run of the query in the same EntityManager yields
>> duplicates A's (with LEFT JOIN FETCH). What happens when you do this:
>> select distinct a from A a join fetch
>> ?
>> How about these two:
>> select a from A a left join fetch
>> select distinct a from A a left join fetch
>> I don't want to give the impression that I'm an expert on the matter, just
>> that I've dealt with this issue and I want to be sure my understanding of
>> things is accurate.
>> --
>> Daryl Stultz
>> _____________________________________
>> 6 Degrees Software and Consulting, Inc.

View raw message