On 23 Jan 2011, at 16:03, Robert Newson wrote: > I can see utility in the original proposal, my only point is whether > it would still be utile if other mechanisms were introduced. You've > clarified that the two cases are distinct, so it seems reasonable to > me now. > > However, I'd hope we'd return the doc and not just the _rev. The only > thing returning the rev itself will do is encourage blind overwrites.
You are correct of course. In my attempt to clarify one issue, I confuddled another. Sorry :) Cheers Jan -- > > B. > > On Sun, Jan 23, 2011 at 2:58 PM, Jan Lehnardt <j...@apache.org> wrote: >> 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 >>>> <dio...@dionne-associates.com> 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 >>>>> >>>>> >>> >> >>
