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
