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.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
