Actually I hadn't realized that the problem only occurred on eagerloading.
Would it make sense to be able to do an alias at the table level? In
other words:
task_parent=aliased(task_table)
mapper(Task,task_table, properties={
'Children' : relation(Task, backref=backref('Parent',
primaryjoin=(and_(task_parent.c.asset==task_table.c.parent_asset,
task_parent.c.name==task_table.c.name)),
remote_side=[task_parent.c.asset,
task_parent.c.name]),
order_by=task_table.c.asset,cascade='all',
lazy=True)
})
Michael Bayer wrote:
> Theres a test case like this which had a behavioral change as of
> 0.5.5, but looking at that, eager loading doesn't come into the picture.
>
> for that particular test, we add foreign_keys=[task.c.parent_asset] to
> the many to one side, and foreign_keys=[None] to the one-to-many
> side. You might need that here just in general.
>
> But for eagerloading I actually don't think we have a solution for
> that right now. the "task_1" comes into the ON clause by way of
> clause adaption, which has a list of columns that it wants to
> "adapt". So "task.name" is either in or not in the list.
>
> I'm thinking of a completely bizarre hack which would be to add a
> Column to the table with the same name as "name", but a different key,
> then setting up primaryjoin using that. But I don't know if that
> would do it.
>
> Otherwise you might just take the easy route and say:
>
> t2 = aliased(Task)
> s.query(Task).join(t2, and_(Task.parent_asset==t2.asset,
> Task.name==t2.name)).options(contains_eager("parent" , alias=t2))
>
>
>
--
David Gardner
Pipeline Tools Programmer
Jim Henson Creature Shop
[email protected]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
