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

Steve Ebersole steve at hibernate.org
Sun Oct 15 12:20:53 EDT 2017


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 at 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 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
>


More information about the hibernate-dev mailing list