On Wed, Nov 17, 2010 at 1:49 PM, Jan Lehnardt <j...@apache.org> wrote: > > On 17 Nov 2010, at 19:24, Paul Davis wrote: > >> On Wed, Nov 17, 2010 at 1:02 PM, rpke...@gmail.com <rpke...@gmail.com> wrote: >>> >>> >>> Sent from my HTC on the Now Network from Sprint! >>> >>> ----- Reply message ----- >>> From: "Luciano Ramalho" <luci...@ramalho.org> >>> Date: Sat, Nov 6, 2010 15:52 >>> Subject: Write race conditions, working without _rev >>> To: <user@couchdb.apache.org> >>> >>> On Fri, Nov 5, 2010 at 2:03 PM, Paul Davis <paul.joseph.da...@gmail.com> >>> wrote: >>>> In the second case, the second person to write the document wins, >>>> erasing any changes the first write's effects. The first writer will >>>> then be in a state where his view of the database will be >>>> inconsistent. The thing his, he can't know because without requiring a >>>> _rev token he'll never get a notification of any sort of error. >>> >>> As I understand, the situation you describe above never happens in >>> practice with CouchDB. A second PUT to the same document _id will >>> always require the _rev attribute, so there's no way to overwrite a >>> previous update by accident. This is one of the best features of >>> CouchDB for document-oriented persistency. >>> >>> >>> -- >>> Luciano Ramalho >>> programador repentista || stand-up programmer >>> Twitter: @luciano >>> >> >> That's true if you don't use _update handlers to hack around that part >> of CouchDB's design. > > Update handlers can't bypass the rev check, they only take the decision > closer to the database. With two concurrent update functions, one will > fail and one will win. > > Cheers > Jan > -- > >
Touché. Jan is quite right, that two simultaneous _update handlers that try and write the incomming doc with the current doc's _rev tag could still fail. They just make the window smaller as they're closer to the db. Paul
