couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Stillwell <>
Subject Re: overwrite on update if _rev not latest?
Date Tue, 26 May 2009 00:35:11 GMT
On Wed, May 13, 2009 at 12:40 PM, Jan Lehnardt <> wrote:
> On 12 May 2009, at 09:28, Michael Stillwell wrote:
>> Is there any way to get CouchDB to overwrite a document (instead of
>> generating a conflict) when updating an existing document with a _rev
>> that does not match the latest _rev?
>> One simple use case for this is that of a user opening up two user
>> profile tabs on a website, then editing both, and submitting both.
>> The second "update" will fail--is there a way to force this through?
>> (I don't particularly care if the second update clobbers some changes
>> from the first.)
> This goes against CouchDB's core design philosophy, so it is unlikely
> that we'll ever get this feature.
> I don't understand enough of you use case (how do "profiles" match
> documents et al). With a doc per profile, you don't get any write conflicts.

Can you explain further why a doc per profile would eliminate write
conflicts?  That's what I was assuming, and so I don't understand how
this helps.

If you need to know the latest revision of a document in order to
modify it, doesn't this make various common key-value use-cases
difficult to code?  (Essentially any situation where two or more tasks
write to the same key/document at around the same time, and you want
the most recent write to win.)

Another example of a problematic situation: a document represents
recent Flickr photos with a particular tag.  If two search tasks
(which query Flickr, then write the response back to couchdb) are
initiated simultaneously, the second save will fail.

I can only think of awkward loopy ways to code around this--is there
some elegant way?  (Also, why does couchdb work this way?  Most (all?)
other "new" key-value stores seem to overwrite previous values without


+44 78 2118 9049

View raw message