Criteria queries incorrectly retrieve associations on FetchMode.JOIN on scroll

Description

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:

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:

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.

Environment

None

Activity

Show:
Kyrill Alyoshin
October 3, 2010, 4:31 AM

Ouch... Just discovered that even with HQL Query (not Criteria), it doesn't work. What happens, is that the first Vendor (with two addresses) is processed correctly. The second Vendor (with two addresses) is processed incorrectly where its last address is not present in the scroll. In other words if you run a unit test in a loop, every Vendor (other than the first one) will be processed incorrectly with the second address dropped.

This is really sad, because now I have to resort to loading addresses for every Vendor in the main loop, n+1 select...

Kyrill Alyoshin
October 3, 2010, 4:34 AM
Edited

This may be related to HHH-1803. This is a biggy.

Kyrill Alyoshin
October 3, 2010, 4:39 AM
Edited

And HHH-1283.

Brett Meyer
April 7, 2014, 5:47 PM

In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.

If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.

Thank you!

Brett Meyer
July 8, 2014, 3:12 PM

Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!

Rejected

Assignee

Unassigned

Reporter

Kyrill Alyoshin

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major