On Nov 4, 2011, at 3:25 AM, Thijs Engels wrote: > I am having some trouble getting the code below to work... running the > code below will give this error message when trying to create a Session > object (last line): > > sqlalchemy.exc.ArgumentError: Could not determine relationship direction > for primaryjoin condition 'ChildArea.session_id==ParentArea.session_id > AND ChildArea.parent_area_id==ParentArea.id', on relationship > ChildArea.parent_area. 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.
the issue is this: > primaryjoin=and_( > "ChildArea.session_id==ParentArea.session_id", > "ChildArea.parent_area_id==ParentArea.id" > ), it makes the mistake described here (note the FAQ overall is being redone, don't worry that this isn't easy to find at the moment): http://www.sqlalchemy.org/trac/wiki/FAQ#ImusingDeclarativeandsettingprimaryjoinsecondaryjoinusinganand_oror_andIamgettinganerrormessageaboutforeignkeys. > > This is what is giving me issues at the moment, and a few questions. > First of course is how to make the code below work, but I am also > wondering what the best practice is with regards to using column names > and/or object and property names when defining foreign keys and > relationships. As the two namings are not in line for my example. > > The ForeignKeyConstraint requires column names, but the primaryjoin > seems to be able to handle various options. Have been skimming through > the documentation to find a declarative example with a compound > foreignkey but have not been able to find one. What would be a best > practice for the primaryjoin? ForeignKeyConstraint is a Core construct. It knows nothing about the ORM or "primaryjoin" or anything like that. It allows strings as it is associated with a Table inline, where it can then pull the parent columns from the parent Table object's ".c" collection. primaryjoin OTOH receives a SQL Expression Language structure as an argument, a Python data structure that represents SQL string, not unlike how a DOM structure represents an XML document. For convenience, when using declarative, this structure can be passed as Python code inside of a string, where eval() is then called upon the string to produce the Python construct. In this case your foreign key constraints match exactly to your relationships so I would think primaryjoin is not needed at all here. (just tried it - you can remove all "primaryjoin" directives here no problem). -- 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.
