> > class Foo(SQLObject):
> > bar = ForeignKey("Baz")
> >
> > Column is Foo.q.bazID
>
> Hm I just realised, this could well be barID, but I doubt it.
> Unfortunately when I worked it out I was doing "player =
> ForeignKey('Player')" and got ".q.playerID", which is a bit ambiguous.
It is barID, not bazID - the name is derived from the name being assigned to.
Despite being, now, understandable, the fact that this differs from standard
behavior of other columns both confuses, and infuriates, like the alien
concept of 'wuv'. Sure, it's good to identify differences, but I -know- how
I programmed my model definition. I don't need SO "helping" me.
Thanks, though, as your example put me on the right track! My code now works.
(Apparently SO doesn't like mixing strings and magical .q. variables. The
SQL was very messed up in my example code.)
- Matthew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
