On May 8, 2008, at 8:40 AM, Bobby Impollonia wrote:
> > That worked, except that I had to skip the secondary kwarg on the > backref. If I include it, I get: > <type 'exceptions.TypeError'>: __init__() got multiple values for > keyword argument 'secondary' > So it seems that it is assuming that I will use the same secondary > table for the backref but not that I am using the same (or, rather, > flipped) join conditions? oh, yeah i just checked and it is taking "secondary". > That doesn't make too much sense to me > (although practically speaking, it is certainly not that big a deal to > have to specify the join conditions again in the backref). I will put > a bug in trac later today to track this issue for .5 theres a reason its like this but I believe the reason is something very historic so I think we will jsut have backref copy the primaryjoin/secondaryjoin of the parent property in all cases unless specified. > Also, this is my first time using a relation with uselist set to false > and I was surprised that if multiple objects meet the condition it > just hands me the first one. Since getting the value of a relation > that has uselist=False is (in my mind) the moral equivalent of using > one() on a query, I had been hoping it would raise if multiple rows > were returned. that again is a behavior change we'd like to implement but we will probably use a new name for it; people are in fact using "uselist" to return just the first value. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
