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. > 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 -- 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.
