[sqlalchemy] Problem with relationships and polymorphism
[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? 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?. It seems like I am missing something here. -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. sqlatest.py Description: Binary data
[sqlalchemy] Problem with relationships and polymorphism
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? 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?. It seems like I am missing something here. -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.
Re: [sqlalchemy] Problem with relationships and polymorphism
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.
Re: [sqlalchemy] Problem with relationships and polymorphism
Am 09.05.2011, 17:50 Uhr, schrieb Michael Bayer mike...@zzzcomputing.com: 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.
