Re: [eclipselink-users] Criteria-API issue

[James Sutherland <jamesssss@xxxxxxxxx>]

When you use join fetch with a 1-m the maxResults is always on the total
rows, this is not a bug, but a fact of join fetch.  Consider using batch
fetch if you want the maxResults to reflect the number of unique objects.

See,
http://java-persistence-performance.blogspot.com/2010/08/batch-fetching-optimizing-object-graph.html


BrianRepko wrote:
> 
> 
> James,
> 
> Thanks - re-ran the test after putting in some more asserts and it turns
> out
> that distinct is needed always as there were duplicates in there.  The SQL
> is
> the same - JPQL vs Criteria.  The issue is max results and join fetches.
> 
> I added the orderBy but to no effect one way or another.
> 
> I'll be logging this as a bug on join fetch and max results.
> 
> Thanks for looking.
> 
> Brian
> 
> ----- Original message -----
> From: James Sutherland <jamesssss@xxxxxxxxx>
> To: eclipselink-users@xxxxxxxxxxx
> Subject: Re: [eclipselink-users] Criteria-API issue with
> Date: Thu, 12 Apr 2012 06:41:42 -0700 (PDT)
> 
> 
> What result do you get back?  Is the SQL the same?
> 
> The issue is that you are using join fetch, this requires fetching all of
> the contents rows, so there are 25*3=75 rows, not 25 rows.  When you use
> maxResults this is on the number of rows, so with 15, I would expect you
> only get back 5 DBList objects.  If you get back 15, my guess the same 5
> are
> being duplicated in the list, or worse don't have all of their contents. 
> Normally you should have an orderBy when using pagination to ensure
> consistent order.
> 
> JPA has some odd rules about when duplicates should be returned or not. 
> Normally EclipseLink would filter the duplicates, but it may be doing this
> differently for JPQL vs Criteria.  I not sure what the JPA spec mandates,
> so
> this could be a bug.  Definitely when you set distinct, EclipseLink will
> filter the duplicates, so this is probably what you are seeing.
> 
> 
> BrianRepko wrote:
>> 
>> I have an entity (DbList) with a List<String> element collection
>> (contents) that is lazily fetched.
>> 
>> I'm trying different ways to load the collection of all entities
>> and eagerly load contents - JPQL and the Criteria API - with or
>> without a firstResult / maxResults.
>> 
>> I'm getting the right number of entities whenever I use JPQL.
>> When I use the Criteria API - I get the right number of entities
>> when using firstResult / maxResults.
>> When I use the Criteria API and an unlimited result set (don't
>> set firstResult/maxResults), then I get the wrong amount of
>> entities back unless I explicitly add a distinct(true) to the
>> CriteriaQuery.
>> 
>> I've attached DbList and Test - this is working but you'll see
>> how I had to add the distinct call to the Criteria "all" case to
>> get it to work.
>> Add distinct on the result limiting run causes it to fail.
>> 
>> Is this a bug or do I not have my Criteria built correctly?
>> 
>> BTW - this is failing the same way on Oracle, H2 and Derby and I
>> have a small project setup if that helps...
>> 
>>  
>> 
> 
> 


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.eclipse.org/forums/index.php?t=thread&frm_id=111&S=1b00bfd151289b297688823a00683aca
EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
Blog:  http://java-persistence-performance.blogspot.com/ Java Persistence
Performance 
-- 
View this message in context: http://old.nabble.com/Criteria-API-issue-with-tp33662834p33708630.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.