Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Rep. bug in R...... 1.0.1?
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <2F720CE9-4C05-4F61-8EAA-98891AF92E1F@gmail.com>
Date: Mon, 20 Sep 2010 13:02:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <72F67E98-EBC3-4CCE-8911-771839BF4448@apache.org>
References: <7EB4EC03-B4C9-42A5-B4AB-48D6CC998DA4@gmail.com>
 <68466957-7751-4052-9FDE-167C0CA9F82E@apache.org>
 <CCDA9A0F-BDA2-4931-AF9A-475E2BA7687D@gmail.com>
 <1A19A6AF-63DE-44CC-BCF0-E117F1ACAB7A@apache.org>
 <2F720CE9-4C05-4F61-8EAA-98891AF92E1F@gmail.com>
To: dev@couchdb.apache.org

Thanks Nikolai!

On 19 Sep 2010, at 15:26, Nikolai Teofilov wrote:

> Hi Jan,
>=20
> I have had difficult time with the spam filter to post massages and =
open simply a ticket:
>=20
> https://issues.apache.org/jira/browse/COUCHDB-885
>=20
> There is also a script that reproduce this behavior inside. After a =
short discussion with Klaus, I am still not sure if this is a bug or =
not, but Please take a look again for sure. Furthermore if you try to =
repeat the steps manually from Futon it behave differently. =20
>=20
> Cheers
> Nikolai
>=20
> On 19.09.2010, at 14:34, Jan Lehnardt wrote:
>=20
>> Hi Nikolai,
>>=20
>> sorry to be terse, but can you provide a short script that
>> exercises the behaviour? Ideally with placeholders for
>> the two CouchDB URLs so we can fill in values for our=20
>> testing environment.
>>=20
>> Cheers
>> Jan
>> --=20
>>=20
>> On 11 Sep 2010, at 20:16, Nikolai Teofilov wrote:
>>=20
>>> Hi Adam,
>>>=20
>>> The words "pull" in step 4 and "push" in step 6 are correct. I =
exchanged the places of the curl commands ...
>>>=20
>>> The idea is common scenario ... to have master db and each slave =
server get local copy of the master, make local changes ... (attach new =
files) and send the modified copy back to the master. The problem =
appears only if the documents have been updated with new attachments and =
only between databases  on two different servers. It looks like by =
sending back a document updated with new attachment will affect the _rev =
number and a kind of side effect appears so if you try to delete those =
document on the remote db the last revision of the document before the =
update will be still in the database. It could be that this is correct =
but I think the delete operation of a document should remove all its =
revisions as well, correct?
>>>=20
>>>=20
>>> 1.   -  make remote_db  (on different machine!)
>>> 2.   -  create a doc  on the  remote_db
>>> 3.   -  make local_db (on different machine from the remote =
couchdb!)
>>> 4.   - (trigger from the local couchdb!)  remote_db->local_db
>>> 5.   - put an attachment on local_db/doc
>>> 6.  - trigger from local couchdb!   local_db -> remote_db
>>> 7.  - try to delete the remote_db/doc
>>>     the result should be the last _rev is deleted but a copy of the =
doc is still in the remote_db with the initial _rev number.
>>>=20
>>> I am almost sure it is a bug because if you try this on a one =
couchdb server there is no such a problem. If you try with document =
without attachment there is no problem as well and the documents in both =
last cases are deleted completely.
>>>=20
>>> Cheers=20
>>> Nikolai
>>>=20
>>>=20
>>> On 10.09.2010, at 01:44, Adam Kocoloski wrote:
>>>=20
>>>> Hi Nikolai, I'm not sure I understand.  In step 4 you said "pull =
......." but what you actually did was push the local (empty?) test =
database to the remote server.  After that the subsequent steps don't =
make sense.  Can you try describing the steps again?  Best,
>>>>=20
>>>> Adam
>>>>=20
>>>=20
>>=20
>=20