[SQLObject] Cached Objects

[Matt G. <ma...@po...>]

I hope this has not been discussed in the archives but I cannot get to 
them at the moment ...

Here's my understanding of SQLObject caching - The caching takes place 
at object and attribute level. Objects are cached by class+id and the 
caches (there's actually one for each class) belong to the connection. 
Attributes are cached per object by wrapping the SQL getter in another 
getter that checks whether the attribute exists first. All fairly 
straightforward ... for a metaclass ;-). Both of these forms of caching 
can be turned off.

In a typical Apache 1.x style web application where there are multiple 
processes, the connection's caching has to be disabled (in general) to 
avoid the problems inherent with multiple, independent caches. There 
will, however, be some SQLObjects that are good candidates for caching 
even in this configuration.

It seems to me that it would be useful to be able to turn off object 
level caching on a class-by-class basis. That is, the connection is 
created with caching enabled but the SQLObjects are never actually cached.

I haven't thought this through well enough but it may also be useful to 
cache objects for the lifetime of a transaction. When loading an object 
via a transaction it would first look to see if the connection had the 
object in its cache and if so return that otherwise it would load the 
object from the database and store it in the transation's caches. The 
transaction's caches would be flushed, probably on commit or rollback. 
This may not be worth the effort but in a multi-process application it 
may be the only form of caching that is viable.

As a side issue, I could personally never imagine turing off the 
attribute caching (_cacheValues=False) as the number of SQL queries is 
quite frightening. Do people really use SQLObject like this and if so, 
why and how do you cope with the load on the database?

Thanks, Matt

-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenationinternet.com
e: ma...@po...