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
