[
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