The confusion point here is that there are two different types of conflict.
1. _rev mismatch on regular write. — This is the quoted scenario. Returning the expected _rev with the error result allows to remove an extra GET request. The replicator never does this. 2. _rev mismatch on replication write (or a client with the all_or_nothing option). The response is always 201, even when a conflict is created, the caller isn't being notified (or maybe it is, but the replicator isn't using this). read-repair function assume that conflicts appear as in 2. Returning the expected _rev in a failed write only happens in 1. Cheers Jan -- On 23 Jan 2011, at 14:23, Robert Dionne wrote: > These are also interesting ideas, but I don't think they adequately satisfy > this particular write-heavy scenario. The client receiving the 409 has in > hand the doc they wished to write and may just to add a > field or update one. A general resolve_conflict function is a good idea for > certain collaborative environments but I don't think would handle this > specific case. > > Having the conflict causing update return the doc that caused it seems really > ideal. I'm still +1 on it > > > > > > > On Jan 23, 2011, at 7:51 AM, Robert Newson wrote: > >> Oooh, crosspost. >> >> Had a similar chat on IRC last night. >> >> I'm -0 on returning the doc during a 409 PUT just because I think >> there are other options that might be preferred. >> >> For example, allowing a read_repair function in ddocs, that would take >> all conflicting revisions as input and return the resolved document as >> output. Or allowing a resolve_conflict function that is called at the >> moment of conflict creation, allowing it to be downgraded to a >> non-conflicting update. >> >> With either, or both, of those mechanisms, the proposed one here is >> unnecessary. >> >> B. >> >> On Sun, Jan 23, 2011 at 12:04 PM, Robert Dionne >> <[email protected]> wrote: >>> +1 >>> >>> this sounds like an excellent idea. >>> >>> >>> On Jan 23, 2011, at 12:21 AM, kowsik wrote: >>> >>>> I've been spending a fair bit of time on profiling the performance >>>> aspects of Couch. One common recurring theme is updating documents on >>>> a write-heavy site. This is currently what happens: >>>> >>>> PUT /db/doc_id >>>> <- 409 indicating conflict >>>> >>>> loop do >>>> GET /db/doc_id >>>> <- 200 >>>> >>>> PUT /db/doc_id >>>> <- 201 (successful and returns the new _rev) >>>> end until we get a 201 >>>> >>>> What would be beneficial is if I can request the "current" doc during >>>> PUT like so: >>>> >>>> PUT /db/doc_id?include_doc=true >>>> <- 409 conflict (but the 'doc' at the current _rev is returned) >>>> >>>> This would allow the caller to simply take the doc that was returned, >>>> update it and try PUT again (eliminate the extra GET). This is >>>> especially valuable when the app is on one geo and the db is in yet >>>> another (think couchone or cloudant). >>>> >>>> 2 cents, >>>> >>>> K. >>>> --- >>>> http://twitter.com/pcapr >>>> http://labs.mudynamics.com >>> >>> >
