[hibernate-dev] <join ... fetch="select"/>

[Sanne Grinovero]

I remember finding secondary fetch options very useful when there's
good chances that the second fetch is prevented by 2nd level caching.

Even when 2nd level caching wasn't an option, we had plenty of very
complex objects so loading one would imly many joins; this would
reduce the number of joins per statement to something the RDBMS would
handle more reasonably in terms of performance. The performance
penalty for having many joins was both a metter of complexity but also
of cardinality of the size of results.

Both these cases were "joined" though at entity level, just tuning the
fetch option, so maybe it's not related to your question?

Thanks,
Sanne



On 13 October 2017 at 14:31, Steve Ebersole <steve at hibernate.org> wrote:
> Hibernate mappings define a feature to allow a secondary table (`<join/>`
> in hbm terms) to be defined as not joined via : `<join ...
> fetch="select"/>`.  This actually creates a subsequent select to load the
> data from the secondary table.
>
> I am trying to figure out how to best incorporate this into the paradigm
> for JDBC statement execution in 6.0.  My first thought was "do we need to
> keep this?".  Does anyone know of a real usage of this feature?  In theory
> it could be useful to some degree along with bytecode enhanced interception
> for lazy-loading individual attributes.  But even then, I'm not sure how
> practically useful that is.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev