incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolai Teofilov <n.teofi...@gmail.com>
Subject Re: Rep. bug in R...... 1.0.1?
Date Sun, 19 Sep 2010 13:26:36 GMT
Hi Jan,

I have had difficult time with the spam filter to post massages and open simply a ticket:

https://issues.apache.org/jira/browse/COUCHDB-885

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.  

Cheers
Nikolai

On 19.09.2010, at 14:34, Jan Lehnardt wrote:

> 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 
> testing environment.
> 
> Cheers
> Jan
> -- 
> 
> On 11 Sep 2010, at 20:16, Nikolai Teofilov wrote:
> 
>> Hi Adam,
>> 
>> The words "pull" in step 4 and "push" in step 6 are correct. I exchanged the places
of the curl commands ...
>> 
>> 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?
>> 
>> 
>> 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.
>> 
>> 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.
>> 
>> Cheers 
>> Nikolai
>> 
>> 
>> On 10.09.2010, at 01:44, Adam Kocoloski wrote:
>> 
>>> 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,
>>> 
>>> Adam
>>> 
>> 
> 


Mime
View raw message