On Mar 28, 2006, at 10:41 PM, Daniel Miller wrote:
> Michael Bayer wrote:
>> Optimistic concurrency checking simply means when you UPDATE or
>> DELETE rows, you insure that the returned row count matches
>> correctly. This is how Hibernate does it, and its how SQLAlchemy
>> does it.
>
> I don't think you've got that quite right. Checking the affected
> row count alone does not guard against most concurrency violations.
> In fact, the only assurance you get from that is that rows being
> updated/deleted have not previously been deleted. It does not
> detect if the data that's being modified has been modified by
> another process or session.
>
Ok, its the most minimal level of concurrency checking. and yes,
thats all there is. I forgot about the version number thing, which
I had indended to add as optional behavior, ie. method #2. method #1
and #3 are both too byzantine for my tastes. i should go add a
ticket for version numbering.
I don't understand the objection -- #3 is the only one that works in the general case without inefficiency as in #1 or attaching extra metadata to user tables as in #2. (SimpleORM uses #3 exclusively. :)
--
Jonathan Ellis
http://spyced.blogspot.com
