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(:
>
> --
> ,,,^..^,,,
