Thanks Klaus, It is somewhat inconvenient way compare to 0.11 single call, but it works! I still cannot understand why adding a new field to the document with Futon does not introduce a conflict but attaching a file does?
Cheers Nikolai On 13.09.2010, at 00:00, Klaus Trainer wrote: > 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. >>>>> >>>> >>> >>> >> > >
