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
