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 <sanne(a)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 <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