what to do about org.hibernate.FetchMode

[gavinking]

With the removal of Criteria, this enumeration is now only used internally.

I guess we could move it into an internal package .... or is it going to come back into fashion somehow?

[gavinking]

See the thing is, I'm really not so sure about this, simply because it's such a basic concept, it feel like it deserves a representation in the root package.

But then, OTOH, it already has an evil almost-twin in org.hibernate.annotations that pretty much supersedes it.

(The one in org.hibernate.annotations has a SUBSELECT member.)

[sebersole]

Conceptually, this has been split out in to org.hibernate.engine.FetchTiming and org.hibernate.engine.FetchStyle. Which, in retrospect, I think are not in the right package either - probably better in org.hibernate.metamodel or org.hibernate.metamodel.mapping

I think we should just drop org.hibernate.FetchMode ultimately, but for now just deprecate.

org.hibernate.annotations.FetchMode is interesting in that, again in retrospect, it would have been better modeling FetchStyle - JPA already gives users jakarta.persistence.FetchType for the corollary to FetchTiming.

[gavinking]

I think we should just drop org.hibernate.FetchMode ultimately, but for now just deprecate.

But is there any user code that was using FetchMode that isn't already broken? I believe it was really only useful with the criteria API, which has already been removed. If that's the case I would say there's no point in deprecating it, and we may as well just move or remove it. But perhaps I'm wrong on that point?

[sebersole]

There is no harm in keeping it where it is and deprecating it. It is still used and I'd be shocked if external code (tools e.g.) do not use it.