LEFT OUTER JOIN subcriteria filters children (Mattias Jiderhamn)

Description

When using the Criteria API with LEFT OUTER JOIN to add criterias to the children, i.e.
criteria.createCriteria("children", JoinFragment.LEFT_OUTER_JOIN)
the child collections will only contain those children matching the criteria. (Even when not using any Filters).

The attached testcase (also found here: http://forum.hibernate.org/viewtopic.php?p=2320786) will explain it in more detail.

Attachments

2
  • 08 Jun 2011, 01:34 PM
  • 05 Sep 2006, 09:19 AM
100% Done
0

Activity

Brett MeyerMarch 7, 2014 at 10:09 PM

Bulk closing tickets resolved in released versions

wOctober 17, 2013 at 8:51 PM

Is there any possibility to get the old behaviour? I want a filtered collection to be fetched as a filtered collection and not be fetched eagerly on first access (very much unneeded queries). This "fix" prevents me from updating since hibernate 3.6.3 (about 2 years now).

Mattias JiderhamnNovember 7, 2012 at 7:12 PM

Or even clearer: explicit fetch mode is not part of the mix (though one might argue that JointType.LEFT_OUTER_JOIN implicates fetch mode)

Mattias JiderhamnNovember 7, 2012 at 7:06 PM

I think we understand each other. I just want to make it perfectly clear to anyone that fetch="join" isn't part of the issue here. (The test case attached in 2006 has fetch="select".) Issue is with JointType.LEFT_OUTER_JOIN only, not fetch mode.

Steve EbersoleNovember 7, 2012 at 6:42 PM

However, as we need left outer join, there is AFAIK no way to turn the fetching off, if the change for this issue is reverted. There would be no way to use Criteria and say "I want left join but not fetch". Removing fetch="join" from the mapping makes no difference. Using HQL would be the only solution. (Or am I mistaken?)

Right, I think this is exactly what I said above. The existing code tries to attribute a double meaning to joinType == JointType.LEFT_OUTER_JOIN. Reusing values to mean 2 things has consistently been a problem with legacy Hibernate code. If there are 2 values that need to be tracked, there should be 2 distinct, dedicated variables to track them. Again, that is what I am looking at doing.

And even "getting rid of the fetch" (if you mean in an automated way based on whether there is a restriction) is extremely difficult to get right in this legacy Criteria API since doing this well would need to look at nested sub-criteria as well and even potentially across sub-criterias. Much much much easier, more consistent and more explainable to say that if you have join fetching in your mapping, thats what you get (period) in a Criteria.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created September 5, 2006 at 9:19 AM
Updated September 2, 2015 at 2:40 PM
Resolved May 4, 2011 at 10:23 PM

Flag notifications