On Feb 19, 2014, at 1:34 PM, Mariano Mara <[email protected]> wrote:
> > > On 19/02/14 15:28, Michael Bayer wrote: >> >> On Feb 19, 2014, at 1:14 PM, Mariano Mara <[email protected]> wrote: >> >>> # relationships >>> runner = relationship("User", foreign_keys=[uid, oid], >>> #primaryjoin=and_("Bet.uid==User.uid", >>> "Bet.oid==User.oid"), >>> ) >>> loader = relationship("User", foreign_keys=[loader_uid, oid]) >>> >> >> you've got the quoting off on that commented-out primaryjoin, here's the >> most direct way to set it up: >> >> runner = relationship("User", >> primaryjoin="and_(foreign(Bet.uid)==User.uid, >> foreign(Bet.oid)==User.oid)", >> ) >> loader = relationship("User", >> primaryjoin="and_(foreign(Bet.loader_uid)==User.uid, >> foreign(Bet.oid)==User.oid)", >> ) >> >> >> >> > > I have tried with the primaryjoin too (although not including the foreign()) > and I hit a different error. Your suggestion -of course- works. > > I am confuse now: when do I use the primaryjoin and/or foreign_keys and/or > foreign? well these approaches are largely interchangeable in the vast majority of cases. your schema here is actually throwing two curveballs at once, one is the usual “more than one foreign key constraint” problem, but the other is that two of these constraints actually share the same column. For example I can also set foreign_keys=[loader_uid] / foreign_keys=[uid], and it configures, because the ‘oid’ column isn’t there to confuse things, but then “oid” isn’t taken into account. Really, SQLA’s “here’s how i figure things out based on foreign key” logic is not quite ready for that specific set of inputs. I’ll add a bug report for it. the approach of primaryjoin with foreign() is the most specific method which leaves the least amount of questions for SQLAlchemy to figure out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
