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 >> >>
