Re: Idea: Piggyback doc on conflict
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 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 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 > > >>> >> >>
Re: Idea: Piggyback doc on conflict
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. B. On Sun, Jan 23, 2011 at 2:58 PM, Jan Lehnardt 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 >>> 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 >> > >
Re: Idea: Piggyback doc on conflict
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 >> 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 >>> >>> >
Re: Idea: Piggyback doc on conflict
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 > 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 >> >>
Re: Idea: Piggyback doc on conflict
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 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 > >
Re: Idea: Piggyback doc on conflict
+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
