>> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/ manual.html#ref_guide_fetch > That sounds good, although it's not standard.
But very, very, useful.. ;) I'm not sure how one can do serious ORM without (something like) this; the fetch = FetchType.LAZY / EAGER stuff is stuff way too static, IMHO. Always wondered why this never made it (http://www.dataservices-connection.com/2008/09/need-for-fetch-plans.htm l) from JDO v2 API (http://db.apache.org/jdo/api20/apidocs/javax/jdo/FetchPlan.html) into the JPA spec, not even in JPA v2 yet AFAIK.. is there any hope a JPA v2.x finally picks this up? -----Original Message----- From: Michael Simons [mailto:[email protected]] Sent: Wednesday, November 18, 2009 11:54 AM To: [email protected] Subject: Re: How work around OpenJPA-1365 Hi Michael, Michael Dick schrieb: > Hi Michael, > > Regarding seeing OPENJPA-1365 on 'vanilla' OpenJPA 1.2.1, I'll have to > take a look at that. It probably happens if the query does not fetch > records from the database. If that's what you're seeing then I just > need to update the JIRA with that info. We are still investigating on this. Please stand by. > > I'm not terribly familiar with JDO. I was under the impression that > OpenJPA's FetchPlans were identical (or nearly identical) to those in JDO. > > To use my example (Employee and Manager) you would do something like this : > OpenJPAEntityManager em = getEntityManager(); > > OpenJPAQuery q = em.createQuery("SELECT m from Manager m "); > q.getFetchPlan().addField(Manager.class, "employees"); > > List<Manager> managers = q.getResultList(); > > There's a lot more in the manual about it, I'd start looking at [1]. > > [1] > > Hope this helps, > -mike > > > On Tue, Nov 17, 2009 at 11:02 AM, Michael Simons > <[email protected] >> 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] >>>> >> >> > ____________________________________________________________ This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original.
