Re: Expression.filterObjects() and SelectQuery

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Aug 25 2006 - 03:28:57 EDT

  • Next message: Mike Kienenberger: "Re: Expression.filterObjects() and SelectQuery"

    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



    This archive was generated by hypermail 2.0.0 : Fri Aug 25 2006 - 03:29:19 EDT