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 <st...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
