Thanks Nikolai! On 19 Sep 2010, at 15:26, Nikolai Teofilov wrote:
> 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 >>>> >>> >> >
