Re: split expressions

[Andrus Adamchik <an...@objectstyle.org>]

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