8:08 p.m.
Criteria queries incorrectly retrieve associations on FetchMode.JOIN on scroll
------------------------------------------------------------------------------
Key: HHH-5622
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5622
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.4
Reporter: Kyrill Alyoshin
I am really hesitant to submit this bug... It is hard to believe that this is actually
happening, but...
Basically, I am using Hibernate core 3.5.4 along with Hibernate Search 3.2.1. I opted to
write my own re-indexer (as opposed to using MassIndexer). So, I have an entity called
Vendor and it is in bi-directional One-To-Many relationship with an entity called
VendorAddress (VendorAddres is not @Indexed). I basically create a criteria query to
retrieve all vendors and FetchMode.JOIN their addresses, and reindex them. Pretty
straightforward stuff, just want the book "Hibernate Search in Action" says.
Here is the code:
{code}
Criteria query = strategy.getQuery(session)
.setResultTransformer(CriteriaSpecification.DISTINCT_ROOT_ENTITY)
.setCacheMode(CacheMode.IGNORE)
.setFetchSize(reindexBatchSize)
.setFlushMode(FlushMode.MANUAL);
int loggingBatch = 1;
long loggingBatchStart = System.currentTimeMillis();
int counter = 1;
ScrollableResults cursor = null;
try {
cursor = query.scroll(ScrollMode.FORWARD_ONLY);
while (cursor.next()) {
Vendor v = (Vendor) cursor.get(0);
System.out.println("Addresses size is " +
v.getAddresses().size());
int count = 0;
for (VendorAddress addr : v.getAddresses()) {
count++;
System.out.println("Address " + count + " is [" +
addr + "]");
}
session.index(cursor.get(0));
if (counter++ % reindexBatchSize == 0) {
session.flushToIndexes();
session.clear();
}
if (loggingBatch++ % loggingBatchSize == 0) {
long stop = System.currentTimeMillis();
logger.info("Re-indexed a batch of {} {} entities in {} millis.
Total left to re-index: {}.",
new Object[]{
loggingBatchSize, typeName,
(stop - loggingBatchStart), (totalCount - counter +
1)}
);
loggingBatchStart = stop;
}
}
//don't delay to commit time, re-index what's left in a batch
immediately
session.flushToIndexes();
session.clear();
}
finally {
//must be closed!
if (cursor != null) {
cursor.close();
}
}
{code}
I have created a integration test that basically creates a Vendor with two addresses,
saves it, and re-indexes it. But what happens is that when the scroll runs, it correctly
detected that there are two records for Vendor (because of a join) but always retrieves
the first address twice!!! Here is the log output from the code above:
{code}
Hibernate:
/* criteria query */ select
this_.vendor_id as vendor1_21_1_,
this_.created_by as created2_21_1_,
this_.created_date as created3_21_1_,
this_.last_modified_by as last4_21_1_,
this_.last_modified_date as last5_21_1_,
this_.centralized_ar_flag as centrali6_21_1_,
this_.enrollment_specialist_id as enrollment9_21_1_,
this_.pm_company_id as pm7_21_1_,
this_.name as name21_1_,
addresses2_.vendor_id as vendor17_21_3_,
addresses2_.addr_id as addr2_3_,
addresses2_.addr_id as addr2_13_0_,
addresses2_.created_by as created3_13_0_,
addresses2_.created_date as created4_13_0_,
addresses2_.last_modified_by as last5_13_0_,
addresses2_.last_modified_date as last6_13_0_,
addresses2_.city as city13_0_,
addresses2_.country_code as country8_13_0_,
addresses2_.addr_line_1 as addr9_13_0_,
addresses2_.addr_line_2 as addr10_13_0_,
addresses2_.addr_line_3 as addr11_13_0_,
addresses2_.postal_code as postal12_13_0_,
addresses2_.state_province_code as state13_13_0_,
addresses2_.vendor_id as vendor17_13_0_,
addresses2_.verified_flag as verified15_13_0_
from
mktg.vendor this_
left outer join
mktg.address addresses2_
on this_.vendor_id=addresses2_.vendor_id
Addresses size is 1
Address 1 is [[VendorAddress@10a063d id = 1]]
Addresses size is 1
Address 1 is [[VendorAddress@10a063d id = 1]]
{code}
So, basically the second address is out of the picture.
Now... The workaround... If I use a simple HQL query and do the same scrolling thing,
everything works beautifully:
"from Vendor v left outer join v.addresses"
I believe this to be a critical bug in how Criteria queries handle scrolling.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira