cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Chainable SelectQuery
Date Tue, 07 Oct 2014 11:37:26 GMT

On Oct 6, 2014, at 8:00 AM, Aristedes Maniatis <ari@maniatis.org> wrote:

> On 6/10/2014 2:10am, Andrus Adamchik wrote:
>> // a single chain from query to object list
>> List<Painting> paintings2 = SelectQuery.query(Painting.class, qualifier2).select(context);
> 
> Since we already have a constructor with the appropriate arguments, why not go for this
as the recommended approach:
> 
>    List<Painting> paintings2 = new SelectQuery(Painting.class, qualifier2).select(context);
> 
> I'm not really sure it makes a difference either way, but just throwing it out there.
They will both work, but the constructor doesn't have generics yet.

Yeah, generics is the key here. Static factory methods allow us to distinguish between entity
and DataRow queries. E.g.:

SelectQuery<DataRow> q = SelectQuery.dataRowQuery(Artist.class);

So I am sorta emphasizing those instead of constructors.

> // static use of "exp" (former "Expression.fromString")
>> // immediate parameter binding
>> Expression qualifier3 = exp("artist.dateOfBirth < $date", "date", c.getTime());
> 
> Can't we parse without any ambiguity:
> 
>    exp("artist.dateOfBirth < $date", c.getTime());

In case of a single parameter you are right. Good point! 



> // static use of 'or' seems cleaner than chaining expressions with 'exp.orExp(..)'
>> List<Painting> paintings4 = SelectQuery.query(Painting.class, or(qualifier2,
qualifier3)).select(context);
> 
> 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.

> 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 :)

Andrus 




Mime
View raw message