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
This archive was generated by hypermail 2.0.0 : Thu Jan 14 2010 - 23:04:21 EST