Re: [hibernate-dev] Why does implicit join translate to inner join?
On Thu, Feb 22, 2018 at 9:11 AM Lukas Eder <lukas.eder(a)gmail.com> wrote:
Hi Steve,
Thanks for your message. Of course, being explicit always has the
advantage of ... being explicit. But my question here is really about the
implicit join feature and how it works.
Sure, but that is also part of the answer. A big part
Not to mention, adjusting the type of SQL join used for implicit
jois
> means I can no longer just look at the query and know what is happening in
> terms of SQL joins - which is bad.
>
Why not? There's just an additional keyword between the generated tables:
LEFT (or if you will, LEFT OUTER).
I think you misunderstand... I was saying that I can no longer look at the
HQL/JPQL and tell what kind of SQL joins will be used for that if it is
dependent on the mapped association. This approach was mentioned earlier
in the thread. But you clarified that you mean that implicit joins ought
to just always be interpreted as an outer join.
You could plugin in your own query handling and interpret implicit joins
however you want. That is current not the most trivial task though.
> Not to mention, IMO interpreting these as inner joins is more OO-ish.
>
I'm curious about that, would you mind elaborating?
Well in normal Java - Idiomatic Java ;) - calling `p.address.city` leads to
a NPE if `p.address` happens to be null, right? To me, using inner joins
naturally follows from that - you are saying no intermediate path is null.
And what's your opinion on the Stream analogy, where the current behaviour
(implicit joins from the context of a SELECT clause) corresponds to
Stream.map() potentially applying filters?
Well 2 things:
1) I personally think its not good form to put null in the output of a
Stream map operation, so to me that in fact does imply a filtering
2) You think its odd that the SELECT clause "applies a filter", but your ok
with the fact that it can expand the query domain (from clause)? I think
that is inconsistent.