Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Criteria-API issue

James,

Looking at my assertions - it seems that the data is loaded - or loads when accessed in the assertion logic.

Persistence.getPersistenceUnit().isLoaded(list,"contents") returns false - but then the contents are there later in the assertion logic.
However if its loading it lazily I don't see that as its not being logged - does that sound right?

I would think on a query.getResultsList() with query hints that the SQL would be run straight away and the collections loaded, but I'm
seeing open bugs in regards to this - and that the collection may still be lazily loaded upon access - and then when accessed, ALL the entities values are loaded?  I don't seem to have a way to see that this isn't just loading them in an N+1 way.

This may work for me in terms of counts but in the end I need to know that the collection has loaded or not for the purposes of serialization to JSON/XML.
And I'm using isLoaded(entity,attribute) to do that...

Thoughts?

Brian

----- Original message -----
From: Brian Repko <brian.repko@xxxxxxxxxxxxxxxxxx>
To: EclipseLink User Discussions <eclipselink-users@xxxxxxxxxxx>
Subject: Re: [eclipselink-users] Criteria-API issue
Date: Wed, 18 Apr 2012 12:00:42 -0500


James,

Thanks for that - read through both part 1 and part 2 (and some others).  I've changed the code to do the following:

        em.getTransaction().begin();
        TypedQuery<DbList> query = em.createQuery("select l from DbList l where l.name like 'test%' order by l.id asc", DbList.class);
        query.setFirstResult(0);
        query.setMaxResults(15);
        query.setHint(QueryHints.BATCH, "l.contents");
        //query.setHint(QueryHints.BATCH_TYPE, BatchFetchType.IN);
        List<DbList> results = query.getResultList();
        em.getTransaction().commit();
        assertResults(results, 15, "JPQL-limited");
        em.clear();

But this is failing in that the list contents are not loaded and I can see in the SQL that the second SQL (for the batch load of contents) is not done - there is only one SQL.  Does batch loading not work for ElementCollection?

FYI - I added the name like clause to make sure that it wasn't the fact that I didn't have a where clause - but I get the same without it.

Brian

----- Original message -----
From: James Sutherland <jamesssss@xxxxxxxxx>
To: eclipselink-users@xxxxxxxxxxx
Subject: Re: [eclipselink-users] Criteria-API issue
Date: Wed, 18 Apr 2012 08:32:30 -0700 (PDT)


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.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users


Back to the top