Make entity graph traversal approach (width-first or depth-first) configurable in Hibernate 6

[exody16]

Hibernate 6 chose to use the width-first graph-traversal for fetch determination. That causes much more joins than Hibernate 5 with depth-first traversal had. As a result, classes with many lazy relations(3+) are performing poor. In some cases the SQL queries are failing because of "Too many tables" error.

In large projects, is not trivial to get rid of lazy relations.
Could be possible to make graph traversal configurable in Hibernate 6, so depth-first can be used when needed?

[sebersole]

We've discussed some options for this in 2 broad cases

• So called internal fetch strategies - for merge and refresh
• User controlled fetch strategies

I don't think we'll go all the way to allowing depth first transversal. If you really feel you want the option to allow depth-first specifically, feel free to continue the discussion here - but be prepared to take on implementing that work yourself.

[beikov]

The problem you are describing has nothing to do with how we traverse the model, but rather with how we determine circularity. In 5, we just collected every AssociationKey (the FK) and stopped join fetching an association if we already saw that AssociationKey before. In 6, we have a stack of AssociationKey, so we will respect the model and not stop join fetching at some seemingly random point.

The behavior is nicely described in the migration guide for EAGER fetching, but also applies for MERGE and REFRESH based fetching: https://github.com/hibernate/hibernate-orm/blob/6.0/migration-guide.adoc#fetch-circularity-determination

Personally, I don't see a problem with what we do now in 6. It's your model that needs to be revisited. We were thinking about a max_fetches/max_tables configuration option in the past though, which would allow stopping to create more than N table references for a query. That discussion didn't go anywhere though because we had no real use cases.

[exody16]

Thank you for your explanation. I understand that supporting the Hibernate 5 way of determining circularity just doesn't make sense. Now, this is a use case in which this max_fetches/max_tablesconfiguration might help. At this point, revisiting the model is the only solution ( I hope that we'll manage to solve the issues).