couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: [proposal] Update Handler Conflict Resolution
Date Thu, 15 Sep 2011 14:20:50 GMT
On Thu, Sep 15, 2011 at 5:58 PM, Jan Lehnardt <jan@apache.org> wrote:
>
> On Sep 11, 2011, at 21:38 , Alexander Shorin wrote:
>
>> Hi!
>>
>> Sorry for stupid question, but is there any reasons why _update
>> handlers should have custom conflict resolution logic while simple
>> document store API not?
>
> They do not.
>
> To update a document through the document REST API, you do:
>
> 1. get document
> 2. change document
> 3. save document
>
> 1. and 3. are operations that go over HTTP.
>
> An update function does this:
>
> 1. get document
> 2. change document
> 3. save document
>
> All of this is triggered with a single HTTP request, but the operations as far as CouchDB
is concerned are exactly the same.
>
> In both situations, when 3 is executed both the validation function and the regular conflict
handling is applied.
>
>
> Cheers
> Jan
> --

I understand this well, but this discussion is about adding some new
confict handlers only for update functions, right?

As for use cases, you could also do:

>
> 1. get document
> 2. change document
> 3. save document
>
> 1. and 3. are operations that go over HTTP.

for update handlers that implements some preprocessor or data
normalization work and there wouldn't be any atomic operation. Real
world example is easy to provide: some server, a lot of old clients,
few new ones and data protocol changing without breaking
compatibility. Wrapping all operations with documents by design
functions we could make changes more safety without external tools.


>
>
>> I think that better to implement some update_conflict() functions
>> which acts like validate_doc_update one - globally for all database,
>> one per design document - instead of dividing documents store logic.
>> This way will make things more clear and rules to be universal, not
>> with exceptions for some cases.
>>
>> In this way update_conflict function could looks like this:
>>
>> function update_conflict(stored_doc, actual_doc, update_handler, userCtx){
>>  ...
>> }
>> where:
>> stored_doc - document which was tried to store, but failed
>> actual_doc - actual document with same id
>> update_handler - null if document was stored by simple API or _update
>> handler function object or any reference to get _update function
>> userCtx - user context object
>>
>> But even this solution would save anyone from race conditions(:
>>
>> --
>> ,,,^..^,,,
>
>

Mime
View raw message