Re: [SQLObject] collision detection strategy

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

On Tue, 2003-05-20 at 23:57, Luke Opperman wrote:
> Bud -

<snip>

> The other thought I'm having right now is that SQLObject seems to simplify some
> of this if you're using cached objects, because now there is only one possible
> object, so it's all on the python side to deal with locking as the developer
> sees fit. but I haven't entirely thought this through.

This assumes that **all** updates are going through SQLObject in a
single process. The lock check should definitely happen in the database
- it's the only part of the system that truly knows.

Obviously, if you've got another process bypassing SQLObject's caching
then you've got other problems anyway ;-).

> 
> Also, transactions or otherwise, it would seem that with cached objects it
> would be possible to support setting and managing what level of locking is
> appropriate on a class(table) or instance(row) or attribute level basis.
> 
> My brain is already fried, so i won't try to think this out anymore.
> 
> - Luke
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss