cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <>
Subject Re: Chainable SelectQuery
Date Tue, 07 Oct 2014 23:41:18 GMT
On 7/10/2014 10:37pm, Andrus Adamchik wrote:

>> Can't we parse without any ambiguity:
>>    exp("artist.dateOfBirth < $date", c.getTime());
> In case of a single parameter you are right. Good point! 

In the case of multiple parameters could we just as easily pass parameters in order for a
cleaner syntax?

    exp("artist.dateOfBirth < $date and = $name", c.getTime(), "adam");

There are lots of APIs that follow this approach right back to the C printf function.

>> // static use of 'or' seems cleaner than chaining expressions with 'exp.orExp(..)'
>>> List<Painting> paintings4 = SelectQuery.query(Painting.class, or(qualifier2,
>> Let's see how this plays out with longer queries:
>>    List<Painting> paintings4 = SelectQuery.query(Painting.class, and(or(qualifier2,
qualifier3), qualifier4)).select(context);
>> That looks a bit like reverse Polish notation. To my mind, this approach is clearer:
>>    List<Painting> paintings4 = new SelectQuery(Painting.class).or(qualifier1).or(qualifier3).and(qualifier4).select(context);
>> Am I misunderstanding the different approaches to this? It appears both are valid
with the patch you are proposing. Also, 
> Yes both are valid. The point of the new one is that deeply nested expressions can not
be easily built within a context of query, so you'd build them separately and then pass the
final object to the query. So query.or/and(..) is sort of a final step in the qualifier assembly.
ExpressionFactory.or/and(..) is to build the clauses you pass in there.

Fair enough. Then we'll keep both approaches as valid and possible? I'd suggest the second
syntax is the one we'd want to push as the introductory approach in the tutorials however...
it is simple and easier to understand without the static imports.

Personally I don't see the pattern with static imports as something I'd use, but perhaps other
people would.

>> I think the use of the words "qualifier" and "expression" are confusing. We use them
interchangeably without much reason. Can we pick one and stick to it?
> I thought about it it too. The original reason for 2 terms was that qualifier is always
an expression, while expression is not always a qualifier (e.g. path expressions used in orderings).
Not sure how to best reconcile it? To add to the confusion I'd even use "filter" instead of
qualifier :)

Certainly 'filter' is a better word that is clearer to the users. But perhaps we are too far
down the rabbit hole now with too many classes called Expression and too many methods already
using that word. How about we keep "Expression" as the thing which you attach to a query and
use a different term in our docs for a "path" to attach to orderings.

In your patch, the Javadocs use qualifier and expression completely interchangeably which
is confusing. Perhaps the word qualifier should go away completely.


Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message