Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <490F4342-2E90-44ED-9A1C-2BE036599826@objectstyle.org>
From: Andrus Adamchik <andrus@objectstyle.org>
To: user@cayenne.apache.org
In-Reply-To: <4B4DBECB.3070300@maniatis.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: split expressions
Date: Thu, 14 Jan 2010 11:10:28 +0200
References: <EF9002DE-F99B-41DA-B782-BD22FC521417@gmail.com>
 <7C9958A1-DED5-4B03-8015-FCF8F75EAF9A@objectstyle.org>
 <4B4D90B3.6080106@maniatis.org>
 <24443385-F9ED-4C91-9C1F-8D8C4C162432@objectstyle.org>
 <4B4DA436.40808@maniatis.org>
 <A930907B-7D84-4812-82DB-632052C4C62E@objectstyle.org>
 <BDAA04BD-104C-4DC8-849A-5765F2A04265@objectstyle.org>
 <4B4DBECB.3070300@maniatis.org>


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