On Nov 8, 2007, at 2:37 PM, [EMAIL PROTECTED] wrote:
>
>
>> heres the structure of: select(from_obj=[t1, t2, t1.join(t2)])
>>
>> select +---> t1 <-------------+
>> |---> t2 <------------|
>> +---> join of t1/t2 ---+
>>
>> t2 and t1 both have two parents, and there are two paths to each of
>> t1
>> and t2 from the head select. so its not a tree in the strict sense.
>>
>> or another one:
>>
>> s1 = t1.select().alias('s1')
>> s2 = t1.select().alias('s2')
>>
>> s3 = s1.union(s2) (two paths to t1: s3->s1->t1, s3->s2->t1)
>>
>> any kind of subquery which references a table at a higher level falls
>> into this category.
>>
> hmm. it's still a tree, just the nodes contain same things (t1). There
> are no cyclic paths to _same_ node in the expression.
yes, there are. select->t1 and select->join of t1/t2 -> t1 .
>
> like x+y+23*(x+1) --- x is used/pointed twice but the expression is
> still a tree.
only if you represent it with two distinct nodes for the two
occurences of "x". SA's expressions don't do it that way (usually).
> is there any case where some t1 (or even subexpr) is translated once
> in
> one way, and then in another branch in another way? e.g. like in the
> above x+y+... first x is to be replaced with its value, but second
> with
> its name (say because its in round brackets - in some now-invented
> syntax of mine ).
there arent on my end, and its true that this scenario wouldn't be
supported with the kinds of translations im doing.
>
> i think there is some mixup between what the expression is, as
> grammar,
> and what it actualy means, and u're trying to solve/combine both in
> one
> thing/visitor. maybe also what it should mean _after the processing.
> While they should be all separate notions, somehow.
> eh, i'm just throwing ideas / alternative view points to play with...
yeah, im starting to head towards being able to support two distinct
nodes for "x" but they mean the same thing. the current trunk does a
litle bit of that now, since the "clone" operation doesn't make a
completely copied result. i think at the end of the day, the only
place it matters that we have "x" represented by three different
objects instead of one is when Select prints out the list of FROM
clauses (it also might matter when we render the columns clause of the
select).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
