couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Idea: Piggyback doc on conflict
Date Sun, 23 Jan 2011 15:03:17 GMT
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 <jan@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
>>> <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