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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev