On Thu, Nov 5, 2009 at 12:17 PM, Daryl Stultz <[email protected]> wrote:
> On Thu, Nov 5, 2009 at 12:52 PM, Michael Dick <[email protected] > >wrote: > > > Can you give the 1.2.x patch attached to OPENJPA-894 a try? There are > some > > limitations with the approach I took (ie if Large Result Sets are used), > > but > > it'd be nice to know whether it works for you. > > > > I'm pretty strapped for time, but I'll try to squeeze it in. > > LEFT JOINS should behave the same way.. > > > I was originally under the impression that JOIN FETCH was somehow different > from a JOIN from an SQL/DB perspective, perhaps because of the bug. If the > duplicates were returned, exactly how is JOIN different than JOIN FETCH? > The > latter returns the parent duplicated for each child along with each child > AND populates each parent with the set of children? What is the difference > between > > select o from A as o > join o.bCol as bCol > > and > > select o from A as o > join fetch o.bCol > > assuming duplicate bug is fixed? > I think I misunderstood your point (I thought the FETCH was implied). A LEFT JOIN FETCH and a JOIN FETCH differ in that the LEFT JOIN FETCH is more inclusive (ie you don't have to have a relation to the right side). The same applies to a LEFT JOIN and a JOIN (no fetch). Adding in the fetch clause: A JOIN FETCH differs from a JOIN in two ways : * You will get one reference to the entity on the left side of the JOIN for every related entity on the right side of the JOIN. * The relationship on the right side of the JOIN will be eagerly loaded. LEFT JOIN FETCH and LEFT JOIN follow the same rules (but again the LEFT part makes the results more inclusive). Sorry for the confusion, I thought you were asking about the difference between a JOIN FETCH and a LEFT JOIN FETCH. Not between a JOIN and a JOIN FETCH. > > In OpenJPA 1.2.1 if you want the duplicate references in your result list > > then you're mostly out of luck. > > > Fortunately I don't. But I don't want them to show up later because I > forgot > the "DISTINCT" keyword... > > > One ugly way to get them is to run the query > > twice (the second time we operate in memory and return the correct > > results). > > If you don't want duplicate references then I _think_ it works out of the > > box (until you run the query in memory . . .). > > > > Meaning without the DISTINCT keyword? I should not get the duplicates now > or > in the future (after bugs fixed) if I include DISTINCT, right (assuming > simple "select distinct o from A as o left join fetch o.bCol")? > > Correct. Distinct should prevent duplicates now and in the future. > -- > Daryl Stultz > _____________________________________ > 6 Degrees Software and Consulting, Inc. > http://www.6degrees.com > mailto:[email protected] >
