FAQ
There is a question which join strategy would be better to use implicitly
when supporting the relationship with the other entity - inner or outer. On
the one hand, the inner join allow to avoid entities with null references
when we want to restrict the result set, on the other hand we can lose these
entities when we not care about those references. Now the outer join is
implicitly used and that results in ability to get the null entity at the
result set. Any thoughts?

--
Regards, Ksenia Khailenko

Search Discussions

  • Andrus Adamchik at Jan 26, 2010 at 11:08 am
    We had an offline conversation about that with Ksenia. I should
    clarify that we are talking about EJBQL "SELECT" clause. As in
    "SELECT p.artist FROM Painting p"

    Andrus
    On Jan 26, 2010, at 12:35 PM, Khailenka Xenia wrote:

    There is a question which join strategy would be better to use
    implicitly
    when supporting the relationship with the other entity - inner or
    outer. On
    the one hand, the inner join allow to avoid entities with null
    references
    when we want to restrict the result set, on the other hand we can
    lose these
    entities when we not care about those references. Now the outer join
    is
    implicitly used and that results in ability to get the null entity
    at the
    result set. Any thoughts?

    --
    Regards, Ksenia Khailenko
  • Andrey Razumovsky at Jan 26, 2010 at 11:20 am
    I'm very surprised it is left join by default. I think it should be inner
    join, as it is also analogue with SelectQuery (e.g. "artist" path in
    expression means inner Join). What does specification say?

    2010/1/26 Andrus Adamchik <andrus@objectstyle.org>
    We had an offline conversation about that with Ksenia. I should clarify
    that we are talking about EJBQL "SELECT" clause. As in "SELECT p.artist
    FROM Painting p"

    Andrus


    On Jan 26, 2010, at 12:35 PM, Khailenka Xenia wrote:

    There is a question which join strategy would be better to use implicitly
    when supporting the relationship with the other entity - inner or outer.
    On
    the one hand, the inner join allow to avoid entities with null references
    when we want to restrict the result set, on the other hand we can lose
    these
    entities when we not care about those references. Now the outer join is
    implicitly used and that results in ability to get the null entity at the
    result set. Any thoughts?

    --
    Regards, Ksenia Khailenko

    --
    Andrey
  • Andrus Adamchik at Jan 26, 2010 at 11:32 am

    On Jan 26, 2010, at 1:19 PM, Andrey Razumovsky wrote:

    I'm very surprised it is left join by default. I think it should be
    inner
    join, as it is also analogue with SelectQuery (e.g. "artist" path in
    expression means inner Join).
    I am somewhat 50/50, or maybe 60/40 in favor of inner. SelectQuery has
    no exact precedent as it doesn't allow for paths in SELECT clause. Of
    course implicit path's in all other places (such as WHERE) result in
    INNER joins. Except for a special case of flattened attributes/
    relationships, that started using OUTER joins since 3.1 (the idea
    being that NULL flattened attributes should be allowed).

    So here the decision is whether the case we are talking about is more
    like a general rule ("a path anywhere in the query results in an inner
    join, unless it is explicitly specified as OUTER"), or more like a
    flattened rule.

    Since I hope in 3.1 we'll allow path+ outer join syntax anywhere in
    the query, I guess the default should be inner.
    What does specification say?
    Nothing useful that I could find except for implicit hint at INNER
    when explaining how COUNT(p.artist) should work (but I didn't search
    extensively). Now I also can't remember why we decided to use OUTER
    JOIN in the first place :-)

    Andrus

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJan 26, '10 at 10:36a
activeJan 26, '10 at 11:32a
posts4
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase