Because of the behavior of 0.7, where ForeignKey objects returned the id of
the row in the joined table, we've been consistently naming our ForeignKeys
"TableId" rather than "Table."
OptimizerId = ForeignKey('Optimizer',cascade=False)
As a result, we're also used to doing queries like:
optimization = Optimization.Select(Optimization.q.OptimizerId ==
I've discovered on our experimental SQLObject 0.9 machine that if migrated
with no changes, this becomes:
optimization = Optimization.Select(Optimization.q.OptimizerIdID ==
So I'm augmenting our sqlmeta class to let us continue to use our current
(admittedly faulty from SQLObject's design POV) implementation of foreign
keys instead of using the correct way, which would end up breaking our
entire codebase. :)
On 8/20/07, Oleg Broytmann <phd@...> wrote:
> On Mon, Aug 20, 2007 at 11:20:27AM -0700, Molly Aplet wrote:
> > In response to this thread, I've assigned myself a bug this week to
> > my group's apps, which currently use 0.7, up to 0.9.
> > I can't find a wiki entry on the Trac page covering how to do this--are
> > there any resources for this transition?
> I don't think so.
> > I know I'll have to change the
> > behavior of all my ForeignKeys,
> ForeignKeys? What's up with ForeignKeys?
> > but is there anything else I should keep a
> > lookout for as I migrate?
> A number of SQLObject._* attributes has been migrated to sqlmeta. And
> this is the only incompatible changes I can remember. There are many new
> features, of course...
> Oleg Broytmann http://phd.pp.ru/ phd@...
> Programmers don't die, they just GOSUB without RETURN.