FAQ
Q1: Do the results of Expression.filterObjects() for all records in a
table and the same expression used in SelectQuery always match?

I hope the answer is "not currently, but once outer joins are
supported, yes", because it will give me the following procedure to
work around the outer join problems:

- Run a query to return a subset of a table
- Run filterObjects() for the remaining troublesome expression


Q2: Are Expressions ambigous when used with Expression.filterObjects()?

Q3: If Expressions are unambigous when used with
Expression.filterObjects(), then why would I want them to be ambigous
for SelectQuery?






--
Øyvind Harboe
http://www.zylin.com

Search Discussions

  • Andrus Adamchik at Aug 25, 2006 at 7:29 am
    Hi,
    On Aug 24, 2006, at 11:43 AM, Øyvind Harboe wrote:
    Q1: Do the results of Expression.filterObjects() for all records in a
    table and the same expression used in SelectQuery always match?

    I hope the answer is "not currently, but once outer joins are
    supported, yes", because it will give me the following procedure to
    work around the outer join problems:

    - Run a query to return a subset of a table
    - Run filterObjects() for the remaining troublesome expression
    Q2: Are Expressions ambigous when used with Expression.filterObjects
    ()?
    Q3: If Expressions are unambigous when used with
    Expression.filterObjects(), then why would I want them to be ambigous
    for SelectQuery?
    Ok, I am getting deeper into this discussion as it is relevant to
    many things we are working on now. Sorry If I repeat something that
    has been discussed before....

    If I recall correctly, the issue was that in-memory evaluation of
    Expression is analogous to outer join behavior, while the generated
    SQL was an inner join?

    As far as I can tell the direction taken by Mike with outer join
    implementation (Mike, correct me if I'm wrong) is to specify
    explicitly whether an outer join is needed. There won't be any
    attempts to second-guess the user. I support such direction with the
    understanding of the problem that I have now.

    But this presents a dilemma on whether to rework in-memory algorithm
    to match the SQL behavior. Consider this expression:

    toA.x = 'A' or toB.y = 'B'

    Should we change Expression in-memory logic to work like a SQL INNER
    join (i.e. expand the expression to "toA != null and toB != null &&
    (toA.x = 'A' or toB.y = 'B')" ?? Besides as we discussed before, JOIN
    semantics may be specified on the query OUTSIDE of the qualifier as a
    special extra clause (this is the case with the JPA spec anyways).

    My initial answer is that we should preserve current in-memory
    behavior, only document the distinction better. This way we will keep
    the expressions as a quick and "lightweight" way of building
    qualifiers, leaving heavy lifting to the much more complex EJB QL
    (aka JPQL) syntax.

    Andrus
  • Mike Kienenberger at Aug 25, 2006 at 3:05 pm

    On 8/25/06, Andrus Adamchik wrote:
    As far as I can tell the direction taken by Mike with outer join
    implementation (Mike, correct me if I'm wrong) is to specify
    explicitly whether an outer join is needed. There won't be any
    attempts to second-guess the user. I support such direction with the
    understanding of the problem that I have now.
    Yes, right now it's done per Expression either with setJoinType() or
    by using a "+" in the path: "toA+.toB+.c"

    If we could be sure that we don't break expected behavior, I'd love to
    have the need for an outer join on an OR or on an inequality
    comparision be automatically detected and translated to an outer join.
    I know that my own understanding isn't great enough to be sure that
    this always produces the correct behavior, though.
  • Øyvind Harboe at Aug 28, 2006 at 6:34 am

    On 8/25/06, Mike Kienenberger wrote:
    On 8/25/06, Andrus Adamchik wrote:
    As far as I can tell the direction taken by Mike with outer join
    implementation (Mike, correct me if I'm wrong) is to specify
    explicitly whether an outer join is needed. There won't be any
    attempts to second-guess the user. I support such direction with the
    understanding of the problem that I have now.
    Yes, right now it's done per Expression either with setJoinType() or
    by using a "+" in the path: "toA+.toB+.c"

    If we could be sure that we don't break expected behavior, I'd love to
    have the need for an outer join on an OR or on an inequality
    comparision be automatically detected and translated to an outer join.
    I know that my own understanding isn't great enough to be sure that
    this always produces the correct behavior, though.
    Any ETA on outer joins?

    Clearly there is difficult technical side to outer joins, but the
    documentation part isn't trivial either, i.e. seemingly straightforward
    expressions are ambiguous.

    --
    Øyvind Harboe
    http://www.zylin.com
  • Mike Kienenberger at Aug 28, 2006 at 3:46 pm
    Øyvind,

    I have finished Outer Joins, although specifying them needs better
    support, but I don't have time to create patches and make sure the
    code is cleaned up -- I have a project due in 4 days.

    I will probably create patches against 1.2 this weekend and attach
    them to the JIRA issue.
    On 8/28/06, Øyvind Harboe wrote:
    On 8/25/06, Mike Kienenberger wrote:
    On 8/25/06, Andrus Adamchik wrote:
    As far as I can tell the direction taken by Mike with outer join
    implementation (Mike, correct me if I'm wrong) is to specify
    explicitly whether an outer join is needed. There won't be any
    attempts to second-guess the user. I support such direction with the
    understanding of the problem that I have now.
    Yes, right now it's done per Expression either with setJoinType() or
    by using a "+" in the path: "toA+.toB+.c"

    If we could be sure that we don't break expected behavior, I'd love to
    have the need for an outer join on an OR or on an inequality
    comparision be automatically detected and translated to an outer join.
    I know that my own understanding isn't great enough to be sure that
    this always produces the correct behavior, though.
    Any ETA on outer joins?

    Clearly there is difficult technical side to outer joins, but the
    documentation part isn't trivial either, i.e. seemingly straightforward
    expressions are ambiguous.

    --
    Øyvind Harboe
    http://www.zylin.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupuser @
categoriescayenne
postedAug 24, '06 at 7:43a
activeAug 28, '06 at 3:46p
posts5
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase