incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaus Trainer <klaus.trai...@web.de>
Subject Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Date Sun, 12 Sep 2010 22:00:45 GMT
You could take all the revs from the _conflicts list, and delete them
with one _bulk_docs call, e.g.:

curl -vX POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
application/json' -d '{"all_or_nothing": true, "docs":[{"_id":"doc",
"_rev":"2-818ecad858044ee3bb6017e938e98411", "_deleted":true},
{"_id":"doc", "_rev":"2-3bf9067dce5f550d9bfcdab1217045e7",
"_deleted":true}, {"_id":"doc",
"_rev":"2-13839535feb250d3d8290998b8af17c3", "_deleted":true}]}'

- Klaus


On Sun, 2010-09-12 at 23:18 +0200, Nikolai Teofilov wrote:
> 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