[SQLObject] Re: SQLObject ways of doing things

[<po...@nl...>]

Thanks for your reply. Couple of comments:

+++++++++++++++
> * 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=3Db where id=3Dy and lastupdated=3D20030101010101
>
> 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.
+++++++++++++++

Couldn't this be as simple as something like the following two lines before=
 sending any update sql to the database:

if hasattr(self,'_updateconttrolfield') :
    updatesqlstring =3D "%s AND %s =3D '%s'"%(updatesqlstring,
                             self._updatecontrolfield,
                             getattr(self,'_updatecontrolvalue',None)

Up to the user to set appropriate values. This could also be used to preven=
t unintended updates (by setting intentionally "wrong" values).



++++++++++++++++
> * 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.
+++++++++++++++

We don't know the new database column values if there are automatically cal=
culated columns like the timestamp column in the previous point (or, surely=
, if an sql function has been used?). I would have thought some sort of ref=
resh (or option to do that) was pretty important after an update. =


Rgds

Paul Mothersdill