[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (HHH-5622) Criteria queries incorrectly retrieve associations on FetchMode.JOIN on scroll

[Kyrill Alyoshin (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38598#action_38598 ] 

Kyrill Alyoshin edited comment on HHH-5622 at 10/2/10 9:40 PM:
---------------------------------------------------------------

And HHH-1283.

      was (Author: kyrill007 at gmail.com):
    And HH-1283.
  
> 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 at 10a063d id = 1]]
> Addresses size is 1
> Address 1 is [[VendorAddress at 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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira