cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <lachlan.d...@gmail.com>
Subject Re: split expressions
Date Fri, 15 Jan 2010 04:03:26 GMT
On 14/01/2010, at 8:40 PM, Aristedes Maniatis wrote:

> On 14/01/10 8:10 PM, Andrus Adamchik wrote:
>> 
>> Artist.PAINTINGS.dot(Painting.EXHIBITS).alias("X").dot(Exhibit.GALLERIES).eq("Y");
> 
> This is a long way from obvious for the most common use of the syntax: combining AND
queries across a to-many join. Sure named aliases might be useful in themselves, maybe, for
someone. I can't personally think of a reason. But the following seems clearer to me:
> 
>  Artist.PAINTINGS.join(Painting.EXHIBITS, Expression.SPLIT_PATH).join(Exhibit.GALLERIES).like("Y")

I can see the benefits of specifically being able to name them as Andrus has suggested, and
it was immediately clear to me what he'd typed. However, for the cases we have in mind (for
which I started off the thread) we're hoping for a solution where it's possible for the second
option also. Otherwise all we'd be doing is attempting to generate a random string to produce
an alias id.

> My overall preference is to make the expression functions slightly more SQL-like, with
words like join and like. Avoiding abstract ideas like 'alias' where they aren't relevant
to the user is part of that same goal. In fact 'alias' has a specific SQL common meaning (table
aliases) which is only going to confuse new users.

Actually aliases can represent more than this, such as subquery results. If the goal be more
closely mapping sql/db semantics rather than abstracting the db and expressing object relational
semantics (i.e., key paths vs table joins) then it's not really an abstract concept as they're
the sorts of things such users expect being all part of sql theory.


Given that 3.1 might not be for a while yet I suppose either way we'll be needing to figure
out what to do in the meantime.

with regards,
--

Lachlan Deck


Mime
View raw message