I think we need to take this to dev...
On Jan 13, 2010, at 2:38 PM, Aristedes Maniatis wrote:
On 13/01/10 11:14 PM, Andrus Adamchik wrote:
On Jan 13, 2010, at 2:02 PM, Andrus Adamchik wrote:
paintings.exhibits.start > $date1 AND paintings.exhibits.name like
'X%'
OR
paintings.exhibits.start < $date2 AND paintings.exhibits.name like
'Y%'
OR
paintings.exhibits.start = $date3 AND paintings.exhibits.name like
'Z%'
here you can't describe the desired behavior with "|", but can with
aliases:
a.start > $date1 AND a.name like 'X%'
OR
b.start < $date2 AND b.name like 'Y%'
OR
c.start = $date3 AND c.name like 'Z%'
Wonder if that's a bad example though, as the intended result can be
obtained without splits... Need to think of a better one. Although
the
idea is that there can be cases when exact control over joins is
needed.
And also, you could express that nicely using the syntax I proposed
where each of the AND operation was MERGE_PATH, and then the
expressions ORed together with SPLIT_PATH. But I do see how aliases
are more flexible (since any part of the final expression can
contain paths which are merged and those which are not, even if they
aren't directly merged as a pair of expressions). But trying to
think of a use case that would not make a sane developer's head
implode.... ?
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.
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")
Is this making some forward progress?
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
