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: <CCDA9A0F-BDA2-4931-AF9A-475E2BA7687D@gmail.com>
Date: Sun, 19 Sep 2010 14:34:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A19A6AF-63DE-44CC-BCF0-E117F1ACAB7A@apache.org>
References: <7EB4EC03-B4C9-42A5-B4AB-48D6CC998DA4@gmail.com>
 <68466957-7751-4052-9FDE-167C0CA9F82E@apache.org>
 <CCDA9A0F-BDA2-4931-AF9A-475E2BA7687D@gmail.com>
To: dev@couchdb.apache.org

Hi Nikolai,

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.

Cheers
Jan
--=20

On 11 Sep 2010, at 20:16, Nikolai Teofilov wrote:

> 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