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
>
This archive was generated by hypermail 2.0.0 : Wed Jan 13 2010 - 07:50:26 EST