incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolai Teofilov <n.teofi...@gmail.com>
Subject Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Date Sun, 12 Sep 2010 21:18:48 GMT
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.
>>> 
>> 
> 
> 


Mime
View raw message