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