Re: Cayenne does not throw an exception when an outer join is attempted

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Aug 17 2006 - 16:54:03 EDT

  • Next message: Andrus Adamchik: "Translating outer joins"

    > It's now looking like QueryAssemblerHelper can also record whether
    > something is an outer join when creating the join list at the same
    > time it's outputting the column names.

    Yes - qualifiers are translated as a separate piece.

    > One thing that is going to be annoying is having to specify an outer
    > join for every expression. I'm thinking we could have an "effective
    > outer join" value which, if not specified on the current Expression,
    > inherits from the parent expression. So an Expression join type by
    > default would be "unspecified" which means ask the parent. Any root
    > expression with unspecified would default to an inner join.

    That's where I disagree - when you build a query, every outer join is
    unique and unrelated to anything else. What I was thinking we can do
    to simplify the semantics specification (and also make expressions
    parsed from strings work the same way as expressions created via
    ExpressionFactory) is add join type to the object path string. E.g.
    use a "+" sign like Oracle did in the past:

    * Inner join: "toArtist"
    * Left outer join: "toArtist+"
    * Longer path with mixed joins: "toGallery+.toAddress"

    This seems like a reasonable non-verbose solution. What do you think?

    Andrus

    On Aug 17, 2006, at 3:34 PM, Mike Kienenberger wrote:
    > On 8/17/06, Mike Kienenberger <mkienen..mail.com> wrote:
    >> On 8/17/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
    >> > > simply have a query.setJoinType(JoinType.OUTER) to enable and
    >> disable
    >> >
    >> > I would say this should be done in Expression, not Query, as this
    >> > affects individual joins.
    >>
    >> Technically, I think it's going to be challenging to implement
    >> this at
    >> the Expression level rather than the query level. By the time the
    >> SelectTranslator gets involved, it looks to me like the joins have
    >> all
    >> already been disassociated with the Expressions. It's unclear to me
    >> whether all of the qualifiers have been disassociated with the
    >> expressions at this point, but I think this wouldn't be a problem.
    >>
    >> At least in Oracle, I need to add a (+) after every outer-joined-
    >> table
    >> column name in the join qualifiers ["db relationship joins"] and
    >> after
    >> every outer-joined-table column name in the selection qualifiers
    >> ["parent qualifier"].
    >>
    >> I think in my own use cases, like Øyvind's, I'm ok with everything
    >> being an outer join if anything is an outer join.
    >
    >
    > Oops. I wasn't quite ready to hit send yet -- I was still working
    > through all of this :-)
    > It's now looking like QueryAssemblerHelper can also record whether
    > something is an outer join when creating the join list at the same
    > time it's outputting the column names.
    >
    > So, perhaps I spoke too soon.
    >
    > One thing that is going to be annoying is having to specify an outer
    > join for every expression. I'm thinking we could have an "effective
    > outer join" value which, if not specified on the current Expression,
    > inherits from the parent expression. So an Expression join type by
    > default would be "unspecified" which means ask the parent. Any root
    > expression with unspecified would default to an inner join.
    >



    This archive was generated by hypermail 2.0.0 : Thu Aug 17 2006 - 16:54:28 EDT