Re: replication bug
On 24 Aug 2010, at 18:26, Nathan Stott wrote: I tried it, didn't fix my issue. Can you open a new JIRA issue for this so we won't forget about it? Cheers Jan -- On Tue, Aug 24, 2010 at 9:38 AM, Adam Kocoloski kocol...@apache.org wrote: Hi Nathan, did you get a chance to see if https://issues.apache.org/jira/browse/COUCHDB-868 fixed this issue? Adam On Aug 23, 2010, at 3:57 PM, Nathan Stott wrote: I've identified a bug in replication in couchdb. Here are the steps to reproduce: Create a user named bubba Create a database with a design document that has attachments. Make this database have bubba as an admin and set a reader role of readme Try to replicate this DB on another machine with credentials for bubba in the URL (http://bubba:passw...@remotemachine:port/mydb) You will receive 401s in the log in attachments. It does not matter whether you give bubba the readme role or not, the results are the same. Remove the attachment and the design doc will replicate fine. Remove the readers from the security object of the DB and the desing doc will replicate fine. This is tested and reproduced on 1.0.1
Replication bug in 1.0.1?
Hi,
I should better ask before I open a ticket. I think it is a kind of replication
bug:
Steps to reproduce on CouchDB 1.01:
1. Create a database 'test' on a CouchDB server. Note must be somewhere on
remote location not local!!!
2. Put document 'doc' to the remote db.
3. Create local database 'test'
4. Pull replication from the local server:
curl -X POST -d '{source:test,target:
'http://remote-location:5984/test' }' http://localhost:5984/_replicate
5. Attach a text file to the replicated document on the local db
6. Push replication from the local server:
curl -X POST -d '{source: 'http://remote-location:5984/test',target:
test }' http://localhost:5984/_replicate
7. Try to DELETE the document on the remote database location.
There are two documents with the same name but different revision numbers. You
can see this just if you try to delete the document.
If you repeat the procedure for another attachment you have to delete two
documents before you delete the whole document record.
The revision number is incremented and the replication makes another copy of
the document with the same name but different revision number on the remote
database. This happens only with documents containing attachments and only by
replication between different databases on different servers.
I was able to reproduce this with CouchdDB (1.0.1) on MacOSX, WinXP and Win7
changing the rules of local and remote servers.
Cheers
Nikolai
Re: Replication bug in 1.0.1?
Hi Nikolai, I'm not sure I understand. In step 4 you said pull replication
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
On Sep 9, 2010, at 8:30 AM, Nikolai Teofilov wrote:
Hi,
I should better ask before I open a ticket. I think it is a kind of
replication bug:
Steps to reproduce on CouchDB 1.01:
1. Create a database 'test' on a CouchDB server. Note must be somewhere on
remote location not local!!!
2. Put document 'doc' to the remote db.
3. Create local database 'test'
4. Pull replication from the local server:
curl -X POST -d '{source:test,target:
'http://remote-location:5984/test' }' http://localhost:5984/_replicate
5. Attach a text file to the replicated document on the local db
6. Push replication from the local server:
curl -X POST -d '{source: 'http://remote-location:5984/test',target:
test }' http://localhost:5984/_replicate
7. Try to DELETE the document on the remote database location.
There are two documents with the same name but different revision numbers.
You can see this just if you try to delete the document.
If you repeat the procedure for another attachment you have to delete two
documents before you delete the whole document record.
The revision number is incremented and the replication makes another copy of
the document with the same name but different revision number on the remote
database. This happens only with documents containing attachments and only by
replication between different databases on different servers.
I was able to reproduce this with CouchdDB (1.0.1) on MacOSX, WinXP and Win7
changing the rules of local and remote servers.
Cheers
Nikolai
Re: replication bug
Hi Nathan, did you get a chance to see if https://issues.apache.org/jira/browse/COUCHDB-868 fixed this issue? Adam On Aug 23, 2010, at 3:57 PM, Nathan Stott wrote: I've identified a bug in replication in couchdb. Here are the steps to reproduce: Create a user named bubba Create a database with a design document that has attachments. Make this database have bubba as an admin and set a reader role of readme Try to replicate this DB on another machine with credentials for bubba in the URL (http://bubba:passw...@remotemachine:port/mydb) You will receive 401s in the log in attachments. It does not matter whether you give bubba the readme role or not, the results are the same. Remove the attachment and the design doc will replicate fine. Remove the readers from the security object of the DB and the desing doc will replicate fine. This is tested and reproduced on 1.0.1
Re: replication bug
I tried it, didn't fix my issue. On Tue, Aug 24, 2010 at 9:38 AM, Adam Kocoloski kocol...@apache.org wrote: Hi Nathan, did you get a chance to see if https://issues.apache.org/jira/browse/COUCHDB-868 fixed this issue? Adam On Aug 23, 2010, at 3:57 PM, Nathan Stott wrote: I've identified a bug in replication in couchdb. Here are the steps to reproduce: Create a user named bubba Create a database with a design document that has attachments. Make this database have bubba as an admin and set a reader role of readme Try to replicate this DB on another machine with credentials for bubba in the URL (http://bubba:passw...@remotemachine:port/mydb) You will receive 401s in the log in attachments. It does not matter whether you give bubba the readme role or not, the results are the same. Remove the attachment and the design doc will replicate fine. Remove the readers from the security object of the DB and the desing doc will replicate fine. This is tested and reproduced on 1.0.1
replication bug
I've identified a bug in replication in couchdb. Here are the steps to reproduce: Create a user named bubba Create a database with a design document that has attachments. Make this database have bubba as an admin and set a reader role of readme Try to replicate this DB on another machine with credentials for bubba in the URL (http://bubba:passw...@remotemachine:port/mydb) You will receive 401s in the log in attachments. It does not matter whether you give bubba the readme role or not, the results are the same. Remove the attachment and the design doc will replicate fine. Remove the readers from the security object of the DB and the desing doc will replicate fine. This is tested and reproduced on 1.0.1
Partial replication bug
Just notice a problem with the API for the replication by doc_ids:
curl -X PUT http://192.168.10.239:5984/test
curl -X PUT http://192.168.10.239/test/doc1 -d '{}'
curl -X PUT http://192.168.10.239/test/doc2 -d '{}'
curl -X PUT http://192.168.10.239/test/doc3 -d '{}'
curl -X PUT http://192.168.10.239/test-replica
curl -X POST http://127.0.0.1:5984/_replicate -d
'{source:test,target:test-replica, doc_ids: [doc1, doc2, doc3]}'
replicate all documents. three documents.
curl -X DELETE http://127.0.0.1:5984/test-replica
create again the database:
curl -X PUT http://127.0.0.1:5984/test-replica
replicate just two of the documents:
curl -X POST http://127.0.0.1:5984/_replicate -d
'{source:test,target:test-replica, doc_ids: [doc1, doc2]}'
will still replicate the all three documents.
Re: Partial replication bug
On Mar 16, 2010, at 1:18 PM, Nikolai Teofilov wrote:
Just notice a problem with the API for the replication by doc_ids:
Thank you for the bug report. Do you mind creating a ticket for it on Jira so
we don't lose track of it?
http://issues.apache.org/jira/browse/COUCHDB
Thanks,
Chris
curl -X PUT http://192.168.10.239:5984/test
curl -X PUT http://192.168.10.239/test/doc1 -d '{}'
curl -X PUT http://192.168.10.239/test/doc2 -d '{}'
curl -X PUT http://192.168.10.239/test/doc3 -d '{}'
curl -X PUT http://192.168.10.239/test-replica
curl -X POST http://127.0.0.1:5984/_replicate -d
'{source:test,target:test-replica, doc_ids: [doc1, doc2,
doc3]}'
replicate all documents. three documents.
curl -X DELETE http://127.0.0.1:5984/test-replica
create again the database:
curl -X PUT http://127.0.0.1:5984/test-replica
replicate just two of the documents:
curl -X POST http://127.0.0.1:5984/_replicate -d
'{source:test,target:test-replica, doc_ids: [doc1, doc2]}'
will still replicate the all three documents.
Re: Partial replication bug
Yep!
I will
Cheers
Nikolai
On 16.03.2010, at 22:18, J Chris Anderson wrote:
On Mar 16, 2010, at 1:18 PM, Nikolai Teofilov wrote:
Just notice a problem with the API for the replication by doc_ids:
Thank you for the bug report. Do you mind creating a ticket for it on Jira so
we don't lose track of it?
http://issues.apache.org/jira/browse/COUCHDB
Thanks,
Chris
curl -X PUT http://192.168.10.239:5984/test
curl -X PUT http://192.168.10.239/test/doc1 -d '{}'
curl -X PUT http://192.168.10.239/test/doc2 -d '{}'
curl -X PUT http://192.168.10.239/test/doc3 -d '{}'
curl -X PUT http://192.168.10.239/test-replica
curl -X POST http://127.0.0.1:5984/_replicate -d
'{source:test,target:test-replica, doc_ids: [doc1, doc2,
doc3]}'
replicate all documents. three documents.
curl -X DELETE http://127.0.0.1:5984/test-replica
create again the database:
curl -X PUT http://127.0.0.1:5984/test-replica
replicate just two of the documents:
curl -X POST http://127.0.0.1:5984/_replicate -d
'{source:test,target:test-replica, doc_ids: [doc1, doc2]}'
will still replicate the all three documents.
