couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [proposal] Update Handler Conflict Resolution
Date Thu, 15 Sep 2011 13:58:12 GMT

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