cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Expression.filterObjects() and SelectQuery
Date Fri, 25 Aug 2006 07:28:57 GMT

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.

View raw message