I put into the wiki's recipe section a working version of all this,
for those who are interested.
Incidentally -- I know the join's ambiguous, but while we're guessing
with cascade_mapper (that is, if it's going to be used as a feature),
we might as well guess intelligently. Does the current behavior make
sense in terms of what people would expect to occur? If separating
the join out into two separate joins and manufacturing two variable
names as composites of the key name and either the class or some
constant doesn't make sense (or, more probably, isn't worth the
development time), I'd be quite happy with it not creating (or
attempting to create) the A.B object, as long as the docs reflect
that behavior.
--G
At 22:01 26/03/2006, Michael Bayer wrote:
im not a huge fan of cascade_mapper for reasons like this.
since you have an ambiguous join, perhaps youre looking for explicit
join conditions ?
http://www.sqlalchemy.org/docs/
adv_datamapping.myt#adv_datamapping_relations_customjoin
On Mar 26, 2006, at 1:05 PM, Gambit wrote:
Hi guys -
I'm not sure this is a bug or not, but if not it might be worth
adding a comment to the documentation.
Using the following schema:
table A:
pk
B_fk_1
B_fk_2
...
table B:
pk
info
After setting up A and B correctly (see attachment), and performing
cascade_mapper(A, B), looking at an instance of class A does not
show any B instances (nor is it unambiguous what they should be
called). There is, I note, a A.B entry, but with the value of
None. Looking at the engine log, it is obvious what is happening -
it is trying to find the B object which has a pk matching both
B_fk_1 AND B_fk_2.
The documentation for cascade_mapper should be updated to either
state that it's not the right tool for this situation, or perhaps a
bug/feature request filed against cascade_mapper.
Incidentally, I am trying, as you can see from the attached larger
sample, to build up to a correctly specified mapper for this
testcase. This information may be in the docs already (if anyone
wants to submit chapter and verse...?).
Cheers!
--G
<multiple_join_test.sql>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
