HHH-18855: Subselect fetches not always generated in the same situation

[leonschenk]

I have come to the conclusion that this must be a bug, because the same query is executed but the effect is different. Here is a testcase that will succeed when fixed.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion. For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-18855

[hibernate-github-bot[bot]]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[leonschenk]

@mbladel Thank you for your review. I will do the required work on the points that you mentioned.

[mbellade]

@leonschenk could you please also test if FetchMode.SUBSELECT with FetchType.EAGER associations also works as expected for find (same as with queries)? Thanks.

[leonschenk]

@leonschenk could you please also test if FetchMode.SUBSELECT with FetchType.EAGER associations also works as expected for find (same as with queries)? Thanks.

There is indeed a problem here. I used the following setup to enable lazy vs eager fetching: @FetchProfileOverride(profile = "lazysubselect", fetch = FetchType.LAZY, mode = FetchMode.SUBSELECT) @FetchProfileOverride(profile = "eagersubselect", fetch = FetchType.EAGER, mode = FetchMode.SUBSELECT)

However, the sqlAst is generated at setup-time where no fetchprofile was active. This means lazy fetchtype was selected, bacause it is the default for manyToMany. The 'cached' sqlAst is used because isLoadPlanReusable returns true (fetchprofile is not registered on the EntityPersister, but it should be because it affects the loadplan actually). Though the described problem has not much to do with the original problem, and may be a succesive ticket.

[mbellade]

I believe the "problem" you mention is not really an issue, it's more of an improvement: if FetchMode.SUBSELECT was never considered for find, then this changes the default behavior - and while for FetchType.LAZY I agree it would make sense, it would be quite different for eager-fetching. Also, I believe if we want to go ahead with this, eager and lazy fetching behaviors should be aligned for consistency - just as they already are for queries.

Could you please try just mapping the association as FetchType.EAGER instead of using @FetchProfileOverride? Maybe it doesn't make a difference, just to fully understand this change.