But something changed since 0.11 ...
In my application I have a master server and several slaves. Each slave pull a
document from the master, attach some data and push it back to the master then
this document can be updated from another slave and so on ... and this works
perfectly in 0.11. I was able to delete the document on the master server with
one single delete call.
Now each attachment on the slave will introduce a conflict so if I have several
attachments on some of the slave machines and if I want to delete after that
this document on the master database I have to delete each document revision
for each attachment and repeat this for each slave ...
Is there a way to delete the document with the whole history with a single API
call?
Thanks
Nikolai
On 12.09.2010, at 22:36, Klaus Trainer wrote:
>> Correct me if I am wrong but there should be message like after the DELETE
>> operation:
>>
>> {"error":"conflict","reason":"Document update conflict."}
>
> ...when you do what?
>
>> but I get:
>>
>> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>>
>> Furthermore I don't understand where does the conflict comes in this
>> situation?
>
> The point is that when using the _bulk_docs API and "all_or_nothing":
> true, documents are written even if the given _rev number doesn't match
> the current one. In that case (_rev number doesn't match), you get a new
> conflict.
>
> - Klaus
>
>
> On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
>> Hi Klaus,
>>
>> Correct me if I am wrong but there should be message like after the DELETE
>> operation:
>>
>> {"error":"conflict","reason":"Document update conflict."}
>>
>> but I get:
>>
>> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>>
>> Furthermore I don't understand where does the conflict comes in this
>> situation?
>>
>> Cheers
>> Nikolai
>>
>>
>> On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908535#action_12908535
>>> ]
>>>
>>> Klaus Trainer commented on COUCHDB-885:
>>> ---------------------------------------
>>>
>>> Note that the procedure I've previously described will create a conflict:
>>>
>>> curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
>>> {"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_conflicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
>>>
>>>> Delete document with attachment fails after replication.
>>>> --------------------------------------------------------
>>>>
>>>> Key: COUCHDB-885
>>>> URL: https://issues.apache.org/jira/browse/COUCHDB-885
>>>> Project: CouchDB
>>>> Issue Type: Bug
>>>> Components: Replication
>>>> Affects Versions: 1.0.1
>>>> Environment: Mac OSX, Windows XP, Windows 7
>>>> Reporter: Nikolai Teofilov
>>>>
>>>> Step to reproduce the bug:
>>>> 1. Make database "test" on a remote couchdb server that reside on a
>>>> different machine!
>>>> 2. Create new document: "http://remote-server:5984/test/doc";
>>>> 3. Create database "test" on the local couchdb server.
>>>> 4. Trigger pull replication http://remote-server:5984/test ->
>>>> http://localhost:5984/test
>>>> 5. Attach a file to the replicated document on the local couchdb server.
>>>> 6. Trigger push replication http://localhost:5984/test ->
>>>> http://remote-server:5984/test
>>>> 7. Delete the replicated document that contain now the attachment on
>>>> remote database.
>>>>
>>>> This operation will delete the last revision of the document (after
>>>> the replication) but the previous revision of the document (before the
>>>> replication) still exist in the database.
>>>> This defect appears only for replications between databases on two
>>>> different couchdb servers, and only for documents that were updated with a
>>>> new attachment.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>
>
>
