Am 09.05.2011, 17:50 Uhr, schrieb Michael Bayer :
On May 9, 2011, at 11:16 AM, Matthias wrote:
[EDIT: Duh, forgot the attachment. Here it is.]
Hello,
I ran into a problem with relationships and polymorphism. I've attached
a
test case which runs on its own and shows my models.
The version as given results in an exception for me:
"ArgumentError: Could not determine join condition between parent/child
tables on relationship UserAddresses.user. Specify a 'primaryjoin'
expression. If 'secondary' is present, 'secondaryjoin' is needed as
well."
So I go ahead and add the primaryjoins:
primaryjoin = (User.id == user_id)
primaryjoin = (Address.id == address_id)
With the primaryjoin in place the code works in 0.7b4, but it throws
another exception in 0.6.6:
"ArgumentError: Could not determine relationship direction for
primaryjoin
condition 'content.id = useraddresses.user_id', on relationship
UserAddresses.user. Ensure that the referencing Column objects have a
ForeignKey present, or are otherwise part of a ForeignKeyConstraint on
their parent Table, or specify the foreign_keys parameter to this
relationship."
Now my main question is: "Why do I need to add the primaryjoins at all?
The selectable to which UserAddresses is mapped, that is a join of
"content" to "useraddresses", can join to the selectables in which User
and Address are mapped, that is a join of "content" to "users" or
"addresses", in more than one way. "users.id" mapped to User is a
foreign key to "content.id" mapped to UserAddresses and
"useraddresses.user_id" mapped to UserAddresses is a foreign key to
"users.id" mapped to User.There's an argument to be made that it can
try to make assumptions in this kind of situation, and perhaps someday
such a feature would be added. But such logic would very likely be
difficult to implement.The existing information that relationship()
attempts to derive is already fairly complicated to perform and has
taken many years to get it (mostly) right, but it tries to stick only to
things it can be 100% sure about. Assuming which foreign key to use
starts to enter the realm of guessing, so I'm not in a hurry to add that
feature.
Thanks for your really informative answer. I can see the point now. Maybe
instead of deriving this information indirectly, it would be better if one
could express it right from the start.
Shouldn't SQLAlchemy be able to generate it from the information
given?".
My other question is: "Is there any specific reason why its working in
0.7b4 and not in 0.6.6?".
when you create the primaryjoin User.id==user_id, in 0.6 this indicates
"content.id=useraddresses.user_id", as you can see the message indicates
(and is not what you intended) - whereas in 0.7 it indicates
"users.id==useraddresses.user_id". This was ticket #1892 and a full
explanation is in the migration guide here:
http://www.sqlalchemy.org/trac/wiki/07Migration#Mappedcolumnattributesreferencethemostspecificcolumnfirst
Ahh I see, SQLAlchemy is getting better every day :) Thank you.
-Matthias
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
