[Zope-dev] time stamp - concurrent editing

[Ender]

"Nai A. Tzeo" wrote:
> 
> Hello,
> 
> I'm a zope newbie and was wondering if anyone on the list know how to solve
> the problem of concurrent editing.  I'm using zope as a front end and SQL
> server as a back end.  Basically, I want to be able to edit a record with
> out having to lock the record so that others can use it but I want to make
> sure that when I update and save my changes that I don't overwrite someone
> elses changes.  I was thinking about time stamping the record every time a
> person grabs the records in update view.  Before the changes are written to
> the database, the timestamps on both the record that's checked out and the
> record that was modified should be compare.  If the timestamp in the
> database is more recent, meaning someone has updated the record, then I
> can't update the record with my changes.  I would need to grab the latest
> copy from the database and add in my changes.  I know this sounds really
> inefficient but I can't think of another way.  If anyone have other ideas or
> thoughts, pass it along.  It will be greatly appreciated.

thoughts,

doing programmtic merging of changes is going to be scary (perhaps
exploring the diffs command that cvs uses (rdiff?), however you do it,
you should probably do some auditing tables to make sure changes are
never discarded completely (depending on app and load). 

scenario  (extermely record dependent). assuming shared document stored
in the db for this example.

joe smoe goes to edit screen. leaves for two week vacation

jane doe goes to edit screen. types in her magnum opus. 

joe comes back, types 'vacation ruled' and saves. 

jane looks back at screen, screams, and takes two year vacation.

purely, adding in changes can't always assume nesc that a doc is always
getting bigger (again this extremely app specific).

regardless, IMO for this type app domain mysql isn't a good db for this
type of app (no transaction support, no stored procs/triggers)

ideas,

switch to a db with real mvcc where you don't have to block your readers
on writers to achieve isolation (something like... postgres). add some
triggers to create audit. use sequences instead of timestamps for
revision ids(store timestamps for human views, but programatically using
the db for ts manipulation and indexing is very db specific and limited
by that db ts internals, sequences achieve the same result, are faster,
and are ansi-sql compliant). if you do decide to do locks, allow temp
locks based on ts, check edit requests on ts of lock and
approve/deny/create new, etc.


kapil