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."

For example:

class Optimization(sqlobject):
  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. :)

Anyway, thanks!


On 8/20/07, Oleg Broytmann <> 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 migrate
> 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     
           Programmers don't die, they just GOSUB without RETURN.