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 20:36:25 GMT
> 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