Re: [SQLObject] Overcoming SQLOBject's non-OO behaviour

[Ian B. <ia...@co...>]

On Mar 26, 2004, at 6:14 PM, David McNab wrote:
> While I've got SQLObject now working nicely with my pyweb.gui web 
> framework in CGI mode and standalone server mode, SQLObject's 
> behaviour under mod_apache is giving me some trouble.
>
> Even when creating/using whole new connection objects, and using these 
> in completely separate table classes, SQLObject seems to be storing 
> stuff globally, and not keeping all its state info encapsulated within 
> each connection object.

I'm not entirely clear what state information you're referring to.  It 
may simply be a bug.

> IMO, this is very non-OO behaviour - when one creates a new connection 
> object, and uses this object in building table classes, SQLObject's 
> behaviour should be the same regardless of whether any classes 
> accessing the same tables have already been created in the same 
> process.

*But*, the class resolution is a bit more complicated, and is stored 
more-or-less globally.

In SQLObject classes don't really belong to connections.  In reality 
they usually do, but it's not unusual to create the class first 
(otherwise createTable wouldn't be useful), or to define the class and 
make the connection configurable, and generally to bind the connection 
to the class after the class is created.  I don't think it would be the 
right decision to make tables/classes belong to connections.

Because of the string->class resolution, we have to store names 
globally, and they have to be unique.  The class registries allow for 
separate sets of classes with overlapping names.

> My workaround is to impose a rule on the user, that within any given 
> apache process, no more than one pyweb.gui application may access the 
> same table. But as you can see, this is a pretty unacceptable 
> limitation.
>
> Is there any way of causing SQLObject to 'clean its slate' and 'forget 
> everything'? If so, what's the best way?

There's several -- some of which probably aren't documented -- but it 
depends on just what information you're thinking of.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org