couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Idea: Piggyback doc on conflict
Date Sun, 23 Jan 2011 14:58:22 GMT
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
>> <dionne@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
>>> 
>>> 
> 


Mime
View raw message