Hi, OpenJPA FetchPlan is a more flexible and clear solution than JPA FETCH JOIN, imo. As you are moving from JDO, you will find FetchPlan familiar as it was originally part of JDO specification. The quick way to control complex fetch is to EntityManager em = ...; OpenJPAEntityManager oem = OpenJPAPersistence.cast(em); FetchPlan plan = oem.getFetchPlan();
// now on the plan interface you can add/reove named groups of attributes (called Fetch Group), add/remove specific fields, set maximum depth of traversal or recursion, or locking mode etc. Michael Simons wrote: > > 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] >>> >> > > > > ----- Pinaki -- View this message in context: http://n2.nabble.com/How-work-around-OpenJPA-1365-tp4017737p4023270.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
