sum up for me what the current bugs youre observing are. the
"foreignkey" parameter is definitely needed for some of your cases.
it un-ambiguates which column in the join condition is "remote", for
a join where its otherwise not clear.
On Jan 19, 2007, at 7:32 AM, svilen wrote:
and that change is in rev 2214, your two test scripts run
unmodified now.
without these changes (pure 0.3.3), adding explicit foreignkey=...
on all relations worked OK in all 39 cases.
With new changes (trunk/2216), B pointing to A (manager pointing to
employee) does not work. B pointing to B is ok, A pointing to A or
B is ok.
sqlalchemy.exceptions.ArgumentError: Cant determine relation
direction for 'manager' on mapper 'Mapper|Manager|Manager' with
primary join '"Manager".manager_id = "Employee".id' - foreign key
columns are present in both the parent and the child's mapped
tables. Specify 'foreignkey' argument.
regardless that foreignkey= argument is there.
see attach.
------
Thanks for the other changes. Here's a fixed polumunion.py. It is
best if typecolname there is always given - it will be used only if
needed (concrete). But by default i've made it fit your present
protocol.
>
<test_case3.py>
<polymunion.py>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
