It sounds like you may be confused - like you are talking about associations. I am talking about "secondary tables".
On Sat, Oct 14, 2017 at 8:07 AM Sanne Grinovero <sa...@hibernate.org> wrote: > 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
