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, how to do that?
kind regards, Michael 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 <[email protected]> wrote: > >> On Tue, Nov 17, 2009 at 9:27 AM, Michael Simons >> <[email protected]>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 a.bs >> ? >> >> How about these two: >> select a from A a left join fetch a.bs >> select distinct a from A a left join fetch a.bs >> >> 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. >> http://www.6degrees.com >> mailto:[email protected] >> >
