"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