doh, was going to send this to dev...
On Jan 14, 2010, at 11:10 AM, Andrus Adamchik wrote:
>
> On Jan 13, 2010, at 2:38 PM, Aristedes Maniatis wrote:
>
>> I've tried to explain the current usage better in the docs, given
>> what I now understand. Please let me know if I misunderstood
>> something. I had originally thought they were there as shortcuts to
>> a path string.
>
> Actually we may start using them that purpose as well in 3.1 when
> and if we merge SelectQuery and EJBQLQuery into a new
> SuperSelectQuery. Now I think I remember that a possibility of
> unifying expressions with EJBQL was considered when designing the
> API for splits. Hence aliases were suggested.
>
>
>> A way think of aliases is that they are markers within part of an
>> expression which give Cayenne hints about merging. Like a query
>> cache key, they are important only if you use the same key twice.
>> But because aliases are created when you create the Expression path
>> string, and then expanded when you construct the query, they can be
>> awkward to use. It would be nicer if the Expression carried not
>> only the idea of the key, but also how it expands and passed that
>> onto the query.
>>
>> Expression e1 = ExpressionFactory.like("path1|
>> paintings.gallery.name", "foo");
>> Expression e2 = ExpressionFactory.like("path2|
>> paintings.gallery.name", "bar");
>>
>> This puts the definition of the alias and the expansion in the same
>> logical place. It would also allow
>>
>> Expression e2 = ExpressionFactory.like("path2|", "bar");
>>
>> to use the alias previously defined. Or to have Cayenne construct
>> an arbitrary random, non-reusable alias:
>>
>> Expression e1 = ExpressionFactory.like("|paintings.gallery.name",
>> "foo");
>>
>> Then you could even define an expression
>>
>> Expression e1 = Expression.fromString("|paintings.gallery.name =
>> foo and |paintings.gallery.name = bar")
>
>
> So the name before the pipe is an alias, right? Then how do we
> create splits in the middle of the path? I guess we can have a more
> complex notation:
>
> Artist
> .PAINTINGS
> .dot(Painting.EXHIBITS).alias("X").dot(Exhibit.GALLERIES).eq("Y");
>
> or setting the path, specifying the number of segments:
>
> Artist
> .PAINTINGS.dot(Painting.EXHIBITS).dot(Exhibit.GALLERIES).alias("X",
> 2);
>
> (s/dot/join/ or whatever)
>
> or the old way:
>
> // this will probably require defining a special Expression subclass
> - KeyValueCondition or something
> // that ensures there's only a single path inside
> ExpressionFactory.like("paintings.gallery.name", "foo").split("X", 2);
>
> So yeah, we are definitely making progress. One remaining case that
> is still not accommodated is when subexpressions are created "in the
> vacuum" with no knowledge of the overall query context. So we need
> to take an existing (possibly nested) conditional expression and
> setup correct splits for one or more of its paths. I guess some
> expression transformer is needed here.
>
> Andrus
>
>
>
>
This archive was generated by hypermail 2.0.0 : Thu Jan 14 2010 - 04:12:14 EST