Re: [SQLObject] Proper object destruction

[Luke O. <lu...@me...>]

Martin -

> The classes are defined in the same file of the WebKit servlet and
> whenever I run the servlet, I get:
>
> File "/usr/local/lib/python2.2/site-packages/SQLObject/SQLObject.py", line
> 170, in __new__
>     assert not classRegistry.has_key(className), "A database object by the
> name %s has already been created" % repr(className)
> AssertionError: A database object by the name 'Events' has already been
> created

Hmm, this error message is slightly misleading, it really ought to say that the
*class* Events has already been created. The reason for the problem is that
SQLObject keeps a module-level dictionary of classes, so that foreignKey and
Join class name references (specified as strings) can be resolved.

So the problem is that the Events class is being created by the metaclass
twice. Because python's import typically won't reload an import unless
explicitly told to, this usually happens because you have two distinct classes
with the same name. However, perhaps due to Webware's behavior of reloading
leaf-level servlets if they've changed, or another quirk of Webware's import
hooks, it would appear the events class is being reloaded.

I would recommend putting the SQLObjects in their own file and importing that
from your servlet (from DBObjects import * or similar).. You'll want to do
this soon anyways, since in order to resolve the name references mentioned
above, you'll need to be importing the object classes for any servlet that
uses them. (Alternatively, in your context's __init__.py you can import each
class to ensure they are all resolved before use, but either way you'll want
them in separate files.) The only downside is that if you aren't using OneShot
or AutoReload in Webkit for development, you'll need to restart the appserver
for every object change.

(It's also possible that you are doing something such as *defining* the Events
class in each servlet that might use it, which would be a simpler cause of
this problem, although less likely. Either way, the above reorganization
should take care of it.)

If this doesn't solve it, let us know.

- Luke