Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of n.teofilov@gmail.com
 designates 209.85.161.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=xMDWcOwYQKUlo1GphvBCCyoXQ38EXGNVqZfclR3qBlaTRCMffO1tDhiOVVl977KyI6
         5vVDnn3Pc07lRWe6u60+UDkQfj99F+JFRQ3iuKyxkA2Wf1dfWLpQF/nYM/NAk5HYw0sY
         PixP55GWIc8SyigtoAf1Rc6XWmDJKPeMCJ+FU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: [jira] Commented: (COUCHDB-885) Delete document with attachment
 fails after replication.
From: Nikolai Teofilov <n.teofilov@gmail.com>
In-Reply-To: <1284328845.14376.37.camel@devil>
Date: Mon, 13 Sep 2010 00:31:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4D7CA5E-592C-4098-976F-E95A132E4C16@gmail.com>
References: <10093035.143001284319652669.JavaMail.jira@thor>
 <B86CD672-4494-4527-9034-7816423FAFFE@gmail.com>
 <1284323785.14376.35.camel@devil>
 <45928934-329E-4472-8CC5-1F1D715E4D96@gmail.com>
 <1284328845.14376.37.camel@devil>
To: dev@couchdb.apache.org

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
=20


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.:
>=20
> 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}]}'
>=20
> - Klaus
>=20
>=20
> On Sun, 2010-09-12 at 23:18 +0200, Nikolai Teofilov wrote:
>> But something changed since 0.11 ...
>>=20
>> 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.=20
>> 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 ...=20
>>=20
>> Is there a way to delete the document with the whole history with a =
single API call?
>>=20
>> Thanks
>> Nikolai
>>=20
>>=20
>>=20
>> On 12.09.2010, at 22:36, Klaus Trainer wrote:
>>=20
>>>> Correct me if I am wrong but there should be message like after the =
DELETE operation:
>>>>=20
>>>> {"error":"conflict","reason":"Document update conflict."}
>>>=20
>>> ...when you do what?
>>>=20
>>>> but I get:
>>>>=20
>>>> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>>>>=20
>>>> Furthermore I don't understand where does the conflict comes in =
this situation?
>>>=20
>>> 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.
>>>=20
>>> - Klaus
>>>=20
>>>=20
>>> On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
>>>> Hi Klaus,
>>>>=20
>>>> Correct me if I am wrong but there should be message like after the =
DELETE operation:
>>>>=20
>>>> {"error":"conflict","reason":"Document update conflict."}
>>>>=20
>>>> but I get:
>>>>=20
>>>> {"ok":true,"id":"doc","rev":"3-9ac5f6d05704bf0b5e427d5b6ce7fc92"}
>>>>=20
>>>> Furthermore I don't understand where does the conflict comes in =
this situation?
>>>>=20
>>>> Cheers
>>>> Nikolai
>>>>=20
>>>>=20
>>>> On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
>>>>=20
>>>>>=20
>>>>>  [ =
https://issues.apache.org/jira/browse/COUCHDB-885?page=3Dcom.atlassian.jir=
a.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1290853=
5#action_12908535 ]=20
>>>>>=20
>>>>> Klaus Trainer commented on COUCHDB-885:
>>>>> ---------------------------------------
>>>>>=20
>>>>> Note that the procedure I've previously described will create a =
conflict:
>>>>>=20
>>>>> curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=3Dtrue
>>>>> =
{"_id":"doc","_rev":"3-b06fcd1c1c9e0ec7c480ee8aa467bf3b","foo":"bar","_con=
flicts":["1-4c6114c65e295552ab1019e2b046b10e"]}
>>>>>=20
>>>>>> Delete document with attachment fails after replication.
>>>>>> --------------------------------------------------------
>>>>>>=20
>>>>>>              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
>>>>>>=20
>>>>>> Step to reproduce the bug:
>>>>>> 1.  Make database "test" on a remote couchdb server that reside =
on a different machine!=20
>>>>>> 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.
>>>>>>=20
>>>>>>    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.
>>>>>=20
>>>>> --=20
>>>>> This message is automatically generated by JIRA.
>>>>> -
>>>>> You can reply to this email to add a comment to the issue online.
>>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>=20
>=20