On Oct 6, 2014, at 8:00 AM, Aristedes Maniatis <a...@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
