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

[Sanne Grinovero]

On 15 October 2017 at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> It sounds like you may be confused - like you are talking about
> associations.  I am talking about "secondary tables".

Right, I was confused. Sorry about that.

So indeed I never found myself needing this. I guess one might have a
reason among the same lines of reducing cardinality in a single SQL
statement (similar to my case with associations) but that seems far
fetched, and there are alternative options to mitigate the problem:
that problem is speficially with having "too many" joins and needing
to trim some one could trim the joins triggered by associations first.
People having an excess of secondary tables have other problems to fix
first :)

+1 to simplify this

Thanks,
Sanne

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