Re: [SQLObject] SQLObject ways of doing things.....

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

On Nov 16, 2003, at 12:39 PM, po...@nl... wrote:
> I'm looking at using SQLObject as a replacement for a similar 
> structure (now a little untidy) in an existing database system. I've 
> run into the following points and would appreciate comments -- there 
> may be ways of doing this with SQLObject that I've overlooked, or 
> these may be things that could be useful additional features. The 
> basic structure is a system-wide sub-class of SQLObject, which is in 
> turn subclassed for each database table.
>
> * Hooks for generic column-level override of _set_ and _get_ -- 
> something like a "beforeWrite" function that can be overridden:
>
> def beforeWrite(self, columnName, value)
>     code to produce newValue
>     self._set_columnName(newValue)
>
> similar for afterRead.

There's no documented way to do this.  _SO_setValue and set both do 
updates directly -- if you override both these methods to call 
beforeWrite, you'd have it.

_SO_selectInit is called after a read, generally.  It will be called 
after an expire() call, but I think it can also be called other times 
-- when you do a select() it will fetch column values since it doesn't 
know if the object exists or not.  I can't remember if _SO_selectInit 
gets called in that case.

> Reason: the existing system has quite a lot of logic for this type of 
> stuff in the central class based on the column name and/or type. To 
> write out individual overrides for each column in each derived class 
> would involve a lot of decentralised code.
>
> * Update control. The existing system passes Mysql timestamp (which 
> are automatically updated on every database update) columns around to 
> avoid update leapfrogging (updated by another user) -- the generated 
> sql is always of type:
>
> update x set a=b where id=y and lastupdated=20030101010101
>
> passing the cursor response back as basis for a confirmation or 
> warning to the user.
>
> Is there an easy way to do this in SQLObject, or could it be put in 
> (perhaps via _updatecontrolfield and _updatecontrolvalue variables)?

No, this doesn't really exist.  Lots of people want it though 
(optimistic locking).  I'm certainly open to implementations, but I'm 
not working on it myself.

> * A generic afterUpdate function that can be overridden -- called each 
> time something is changed in the database (used to tidy up non-column 
> variables, issue a self.expire() to force re-lookup of column values, 
> getting the new timestamp for any further updates, etc.).

We actually don't do an expire after an update, on the assumption we 
already know what our new column values are.  If you have dependent 
non-column variables, overriding _set_* as necessary may be sufficient 
to keep them in sync.  Otherwise you'd have to put in a hook in 
_SO_setValue and set.

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