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