I would note that the relation you have doesn't need the "foreign
keys" setting if you create the join conditions from the actual table
that the foreign keys reference:
Child1.left_child2 = relation(Child2, secondary = secondary_table,
primaryjoin = Parent.id == secondary_table.c.right_id,
secondaryjoin = Parent.id == secondary_table.c.left_id,
uselist = False)
But that's not the cause of the issue here. Its very unlikely this
particular test case will work in version 0.4 since the query adaption
flexibility is just not there. its a self-referential eagerloading
joined table inheritance join, with the extra twist of the "limiting"
aliasing that occurs when you use LIMIT (or first()/one(), etc.) -
SQLA couldn't handle any self-referential eager loading until 0.4 at
all so this is not surprising.
The test case does work however in the 0.5 branch where query adaption
and the methodlogies of eager loading have been greatly
strengthened...the fact that it worked "out of the box" there suggests
that the 0.4 branch would need 0.5's approach to achieve the correct
results, which is too significant of a change for 0.4 at this point.
In 0.5, the SQL would produce correct results but was still inserting
an extra "child1" reference in there, so r4691 of the 0.5 branch fixes
this. An extra test which validates the exact SQL was added.
More SQL validation tests need to be added to 0.5's "inheritance
query" test suite which test eager loading from joined table mappers -
I have a suspicion that other tests which were returning correct
results may still have been introducing one too many tables into the
query for a similar reason as this.
On May 8, 2008, at 7:50 PM, Bobby Impollonia wrote:
>
> Another issue with this relation is that it doesn't like being
> eagerloaded.
> Using the same model from my first post (with the broken backref
> removed or fixed):
> session.query(Child1).options(eagerload('left_child2')).first()
> Generates the sql:
> SELECT anon_1.child1_id AS anon_1_child1_id, anon_1.parent_id AS
> anon_1_parent_id, anon_1.parent_cls AS anon_1_parent_cls,
> anon_2.child2_id AS anon_2_child2_id, anon_2.parent_id AS
> anon_2_parent_id, anon_2.parent_cls AS anon_2_parent_cls
> FROM (SELECT child1.id AS child1_id, parent.id AS parent_id,
> parent.cls AS parent_cls, parent.oid AS parent_oid
> FROM parent JOIN child1 ON parent.id = child1.id ORDER BY parent.oid
> LIMIT 1 OFFSET 0) AS anon_1 LEFT OUTER JOIN secondary AS secondary_1
> ON anon_1.child1_id = secondary_1.right_id LEFT OUTER JOIN (SELECT
> anon_1.child1_id AS anon_1_child1_id, anon_1.parent_id AS
> anon_1_parent_id, anon_1.parent_cls AS anon_1_parent_cls, child2.id AS
> child2_id
> FROM (SELECT child1.id AS child1_id, parent.id AS parent_id,
> parent.cls AS parent_cls, parent.oid AS parent_oid
> FROM parent JOIN child1 ON parent.id = child1.id ORDER BY parent.oid
> LIMIT 1 OFFSET 0) AS anon_1 JOIN child2 ON anon_1.parent_id =
> child2.id) AS anon_2 ON anon_2.child2_id = secondary_1.left_id ORDER
> BY anon_1.oid, secondary_1.oid
>
> Which fails with:
> (OperationalError) no such column: anon_2.parent_id
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
