After much fruitless tweaking of my mappings, I finally stumbled across the FAQ item that says:



First, did I miss this in the documentation?

I didn't see it in the documentation for either the .NET or Java version. Isn't this the kind of thing that should be in the doc? Why put it in the FAQ alone?

Second, and more importantly -- WHY?

I've searched JIRA and the forums and I can't find any discussion of WHY Hibernate made this change (I'm pretty sure HQL queries in Hibernate2 honored the mapping).

Can anyone help me understand?
Is this a bug, a "lesser of two evils", or a design decision?

Thanks

H2 behaviour was the same.

It was a design decision that in my view is 100% correct. It allows great flexibility in defining the load behaviour in the query. I have a preference to define little in the HBMs and control load behaviour with the queries. This only applies to HQL. Use Critera queries if you want it to apply.

Thanks for responding so promptly!

I'm glad an actual Hibernate Team Member responded, and I'm glad to hear that it was a design decision. I'd like to humbly challenge it, and I'd appreciate your feedback again.

I try to define little in the HBMs as well, but in some cases, such as when I know that I always want to load a particular many-to-one association, I appreciate that I can configure the mapping to do so. But it kills me to have to specify joins, fetching, and aliases in every HQL query.

I agree that there's great flexibility in being able to specify eager fetching in HQL, and it's also great that HQL queries don't have to honor the mapping.

However, I'd say that the design decision to always ignore the mapping's outer-join settings doesn't allow flexibility, but limits it.

Wouldn't it be more flexible to allow the developer to choose whether HQL honors outer-join settings?

Certainly it would be a pain to modify HQL so that the developer can specify expressions that say "don't outer join to this", plus it would just be ugly.

However, what about one or more of the following:

• Allow the developer to specify whether an IQuery should honor the mapping's outer-joins?
• Or allow it as an option on the Configuration? (Personally, I would always leave it on).

It seems to me that would provide more flexibility while reducing confusion and extra code. Useful enough to submit to JIRA?

One more question...

If I wanted to try making this enhancement to the HQL engine myself, do you have any thoughts on how difficult it would be?

Thanks!

The "always load this association or collection" guarantee is mapped with the 'lazy' attribute. The 'join' attribute defines _how_ it is loaded.

In fact, if at all, Criteria should also ignore the 'fetch' mapping attribute, allowing the user to completely define, not override the mapped fetch strategy. (Note that I am _not_ talking about the fetch plan, which is defined with the 'lazy' attribute and _not_ ignored by any query API). This would align Criteria with HQL behavior.

The reason this will never happen is because it would break all existing Hibernate applications and there is no easy upgrade path.

Thanks for joining in, Christian.

I've read "Short Primer On Fetching Strategies" recently and I believe I understand the difference between "lazy" fetch plans and "join" fetch strategies.

Speaking of the "lazy" setting, both Query and Criteria do honor the "lazy" setting (as far as I know) , so why not honor the "join" setting? Together they have a big impact on how much SQL is executed -- it's strange to abandon one and not the other.

It is interesting that Criteria behaves differently, but I'd rather Query be more like Criteria than the other way around. (I wonder why Criteria is different?)

I agree that Criteria and Query ought to work the same way, but I'd still argue that how they behave w/r/t the mapping is something that the developer should be able to configure.

How is it not an easy upgrade path to continue with the default behavior (ignoring "join" in Query but not in Criteria) but provide configuration or IQuery/Criteria properties to allow the developer to override how those classes behave with respect to mapping settings?

Seems like that wouldn't break anything. The developer would have to know that those settings were available and then explicitly override them in order for behavior to change and break anything.

You are maybe one of five people who even mentioned that this difference bothers them in some way, in probably 5 years. It's simply legacy behavior and we don't add a configuration switch without good reason. "Looks better" is not a good reason.

Also: I strongly believe that you more often want to _disable_ join fetching than _enable_ it. So the way to go is to patch the Criteria classes if that bothers you too much or work with Steve on the Hibernate 3.3. query parser on which the new Criteria will be built (HQL/Criteria unification is the goal here, not sure this will be unified). Submit a JIRA feature request and see if you can help.