openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <michael.d.d...@gmail.com>
Subject Re: Eager fetch leads to out of bounds error
Date Thu, 05 Nov 2009 17:52:24 GMT
On Thu, Nov 5, 2009 at 10:26 AM, Daryl Stultz <daryl@6degrees.com> wrote:

> On Thu, Nov 5, 2009 at 11:10 AM, Michael Dick <michael.d.dick@gmail.com
> >wrote:
>
> > A JOIN FETCH will eagerly load the collection for you, but should return
> > one reference to the entity for each element in the collection. I'm
> > working on fixing this under OPENJPA-894 (proceeding slowly though).
>
>
> Yes, I discovered this bug a month or so ago which led me to change my
> approach for using fetch joins to modifying the fetch plan on the query.
> Now
> I've run into this other problem.
>

I was afraid of that. I haven't kept up with the mailing lists as well as
I'd like to. In any event you are hitting a bug in FetchPlans.. Just thought
I'd throw out the vendor agnostic solution in case you hadn't seen it.

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.

>
>
> > When it's all working you could use a query like this :
> > Query q = em.createQuery("SELECT DISTINCT o from A as o JOIN FETCH
> > o.bCol");
> >
> >
> So this doesn't work now? (Or is it simply that DISTINCT is not required on
> first pass due to the bug?)
>

The latter. DISTINCT is not required due to the bug.


> Should LEFT JOIN FETCH work the same way?
>

LEFT JOINS should behave the same way.. The only difference is that it will
return entities from the LEFT side which do not 'match' any entities on the
RIGHT side..

ie
    SELECT m from Manager m LEFT JOIN FETCH m.employees
includes Managers with no employee.

    SELECT m from Manager m JOIN FETCH m.employees
only returns Managers which have a an employee in the employees collection..



> I've experienced 894 directly but I don't fully understand 1365. If I have
> OpenJPA 1.2.1, what are my options?
>
>
OPENJPA-1365 is a change in the way we handle distinct results. Previously
we just added in the DISTINCT keyword to the SQL statement and relied on
that to return the correct results. This doesn't work if DISTINCT is applied
to multiple tables.

The best example is buried in a longish email I wrote to the dev mailing
list :
http://n2.nabble.com/How-should-we-handle-the-JPQL-DISTINCT-keyword-td3908400.html#a3908400

In OpenJPA 1.2.1 if you want the duplicate references in your result list
then you're mostly out of luck. 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 . . .).

-mike



> Thanks.
>
> --
> Daryl Stultz
> _____________________________________
> 6 Degrees Software and Consulting, Inc.
> http://www.6degrees.com
> mailto:daryl@6degrees.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message