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