Relation Bug in SA?

[Affect]

Hello:

When I use the foreign_keys argument to the relation function in the
mapper of SA, I get the following error:

ArgumentError: Could not determine relation direction for primaryjoin
condition 'drm_owners.owner_id = drm_contract_royalties.contract_id',
on relation Royalty.owner. Specify the 'foreign_keys' argument to
indicate which columns on the relation are foreign.

This error only shows when the 'backref' argument is specified and not
otherwise! Is this a bug in alchemy or am I missing something?

Here's the mapper conf:
===================
mapper(Royalty, royalties_table)
mapper(Owner, owners_table,
properties = {
'works': relation(Work, backref='owner'),
'royalty': relation(Royalty,

primaryjoin=owners_table.c.owner_id==royalties_table.c.contract_id,
foreign_keys=[royalties_table.c.contract_id],
backref='owner')
})

So, if I remove the 'backref' argument from the call to 'relation',
the relation works, but of course I lose the backref 'owner'.

Thanks!

[Bobby Impollonia]

The error is complaining about the backref ("on relation
Royalty.owner"), so it makes sense that it would go away if you remove
the backref.

The error says that you need to specify foreign_keys for the backref,
so you should try that. i.e, change
backref='owner'
to
backref=backref('owner', foreign_keys = [owners_table.c.owner_id])

[Michael Bayer]

the "foreign keys" argument as yet is not propagated to the backref (the
primaryjoin is), I should look into fixing that, but for now use
backref=backref('owner', primaryjoin=pj, foreign_keys=[the foreign keys]).

[Affect]

Thank you, Bobby and Michael. This seems to work now.

I'm still waiting for your book, Michael. Hope it comes soon!

A.

[Michael Bayer]

I've committed this change to the trunk and it does have a behavior
change, here's the changelog:

- The "foreign_keys" argument of relation() will now propagate
automatically to the backref in the same way that
primaryjoin and secondaryjoin do. For the extremely
rare use case where the backref of a relation() has
intentionally different "foreign_keys" configured, both sides
now need to be configured explicity (if they do in fact require
this setting, see the next note...).

- ...the only known (and really, really rare) use case where a
different foreign_keys setting was used on the forwards/backwards
side, a composite foreign key that partially points to its own
columns, has been enhanced such that the fk->itself aspect of the
relation won't be used to determine relation direction.