[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908518#action_12908518 ] Sebastian Cohnen commented on COUCHDB-885: -- I cannot reproduce. But I'm not sure if I understand your steps correctly, so I've written a bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to execute your steps. Could you have a look and verify that I understood your steps correctly? Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database test on a remote couchdb server that reside on a different machine! 2. Create new document: http://remote-server:5984/test/doc; 3. Create database test on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test - http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test - http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
In step 7. delete document on the remote database not on the local. Cheers Nikolai On 12.09.2010, at 20:25, Sebastian Cohnen (JIRA) wrote: [ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908518#action_12908518 ] Sebastian Cohnen commented on COUCHDB-885: -- I cannot reproduce. But I'm not sure if I understand your steps correctly, so I've written a bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to execute your steps. Could you have a look and verify that I understood your steps correctly? Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database test on a remote couchdb server that reside on a different machine! 2. Create new document: http://remote-server:5984/test/doc; 3. Create database test on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test - http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test - http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908528#action_12908528 ] Sebastian Cohnen commented on COUCHDB-885: -- okay, got an error in my script (I've updated the paste). Now I can confirm the behavior. Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database test on a remote couchdb server that reside on a different machine! 2. Create new document: http://remote-server:5984/test/doc; 3. Create database test on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test - http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test - http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
I've updated the script and can confirm the issue. On 12.09.2010, at 20:47, Nikolai Teofilov wrote: In step 7. delete document on the remote database not on the local. Cheers Nikolai On 12.09.2010, at 20:25, Sebastian Cohnen (JIRA) wrote: [ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908518#action_12908518 ] Sebastian Cohnen commented on COUCHDB-885: -- I cannot reproduce. But I'm not sure if I understand your steps correctly, so I've written a bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to execute your steps. Could you have a look and verify that I understood your steps correctly? Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database test on a remote couchdb server that reside on a different machine! 2. Create new document: http://remote-server:5984/test/doc; 3. Create database test on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test - http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test - http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Hi Sebastian! If you try now the same sequence on two databases residing on a one server there is no such a problem so i think this is a replication bug that introduce a conflict like Klaus said, but there shouldn't be a conflict. Cheers, Nikolai On 12.09.2010, at 21:05, Sebastian Cohnen wrote: I've updated the script and can confirm the issue. On 12.09.2010, at 20:47, Nikolai Teofilov wrote: In step 7. delete document on the remote database not on the local. Cheers Nikolai On 12.09.2010, at 20:25, Sebastian Cohnen (JIRA) wrote: [ https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908518#action_12908518 ] Sebastian Cohnen commented on COUCHDB-885: -- I cannot reproduce. But I'm not sure if I understand your steps correctly, so I've written a bash script (see http://www.friendpaste.com/6SrHCU1lseUURuwTJEpCpk) to execute your steps. Could you have a look and verify that I understood your steps correctly? Delete document with attachment fails after replication. Key: COUCHDB-885 URL: https://issues.apache.org/jira/browse/COUCHDB-885 Project: CouchDB Issue Type: Bug Components: Replication Affects Versions: 1.0.1 Environment: Mac OSX, Windows XP, Windows 7 Reporter: Nikolai Teofilov Step to reproduce the bug: 1. Make database test on a remote couchdb server that reside on a different machine! 2. Create new document: http://remote-server:5984/test/doc; 3. Create database test on the local couchdb server. 4. Trigger pull replication http://remote-server:5984/test - http://localhost:5984/test 5. Attach a file to the replicated document on the local couchdb server. 6. Trigger push replication http://localhost:5984/test - http://remote-server:5984/test 7. Delete the replicated document that contain now the attachment on remote database. This operation will delete the last revision of the document (after the replication) but the previous revision of the document (before the replication) still exist in the database. This defect appears only for replications between databases on two different couchdb servers, and only for documents that were updated with a new attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908531#action_12908531
]
Klaus Trainer commented on COUCHDB-885:
---
There is an easier way (only three steps) to get something like that. It
doesn't necessarily involve attachments and replication.
curl -X PUT http://127.0.0.1:5984/foobase/doc -d '{foo:bar}
curl -X POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
application/json' -d '{all_or_nothing: true, docs:[{_id: doc,
_rev:2-0e871ef78849b0c206091f1a7af6ec41, foo:bar}]}'
curl -X DELETE
http://127.0.0.1:5984/foobase/doc?rev=3-b06fcd1c1c9e0ec7c480ee8aa467bf3b
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database test on a remote couchdb server that reside on a
different machine!
2. Create new document: http://remote-server:5984/test/doc;
3. Create database test on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test -
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test -
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on remote
database.
This operation will delete the last revision of the document (after the
replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two different
couchdb servers, and only for documents that were updated with a new
attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908535#action_12908535
]
Klaus Trainer commented on COUCHDB-885:
---
Note that the procedure I've previously described will create a conflict:
curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
{_id:doc,_rev:3-b06fcd1c1c9e0ec7c480ee8aa467bf3b,foo:bar,_conflicts:[1-4c6114c65e295552ab1019e2b046b10e]}
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database test on a remote couchdb server that reside on a
different machine!
2. Create new document: http://remote-server:5984/test/doc;
3. Create database test on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test -
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test -
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on remote
database.
This operation will delete the last revision of the document (after the
replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two different
couchdb servers, and only for documents that were updated with a new
attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Hi Klaus,
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this situation?
Cheers
Nikolai
On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908535#action_12908535
]
Klaus Trainer commented on COUCHDB-885:
---
Note that the procedure I've previously described will create a conflict:
curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
{_id:doc,_rev:3-b06fcd1c1c9e0ec7c480ee8aa467bf3b,foo:bar,_conflicts:[1-4c6114c65e295552ab1019e2b046b10e]}
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database test on a remote couchdb server that reside on a
different machine!
2. Create new document: http://remote-server:5984/test/doc;
3. Create database test on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test -
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test -
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on remote
database.
This operation will delete the last revision of the document (after the
replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two different
couchdb servers, and only for documents that were updated with a new
attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
But something changed since 0.11 ...
In my application I have a master server and several slaves. Each slave pull a
document from the master, attach some data and push it back to the master then
this document can be updated from another slave and so on ... and this works
perfectly in 0.11. I was able to delete the document on the master server with
one single delete call.
Now each attachment on the slave will introduce a conflict so if I have several
attachments on some of the slave machines and if I want to delete after that
this document on the master database I have to delete each document revision
for each attachment and repeat this for each slave ...
Is there a way to delete the document with the whole history with a single API
call?
Thanks
Nikolai
On 12.09.2010, at 22:36, Klaus Trainer wrote:
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
...when you do what?
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this
situation?
The point is that when using the _bulk_docs API and all_or_nothing:
true, documents are written even if the given _rev number doesn't match
the current one. In that case (_rev number doesn't match), you get a new
conflict.
- Klaus
On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
Hi Klaus,
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this
situation?
Cheers
Nikolai
On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908535#action_12908535
]
Klaus Trainer commented on COUCHDB-885:
---
Note that the procedure I've previously described will create a conflict:
curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
{_id:doc,_rev:3-b06fcd1c1c9e0ec7c480ee8aa467bf3b,foo:bar,_conflicts:[1-4c6114c65e295552ab1019e2b046b10e]}
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database test on a remote couchdb server that reside on a
different machine!
2. Create new document: http://remote-server:5984/test/doc;
3. Create database test on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test -
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test -
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on
remote database.
This operation will delete the last revision of the document (after
the replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two
different couchdb servers, and only for documents that were updated with a
new attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
You could take all the revs from the _conflicts list, and delete them
with one _bulk_docs call, e.g.:
curl -vX POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
application/json' -d '{all_or_nothing: true, docs:[{_id:doc,
_rev:2-818ecad858044ee3bb6017e938e98411, _deleted:true},
{_id:doc, _rev:2-3bf9067dce5f550d9bfcdab1217045e7,
_deleted:true}, {_id:doc,
_rev:2-13839535feb250d3d8290998b8af17c3, _deleted:true}]}'
- Klaus
On Sun, 2010-09-12 at 23:18 +0200, Nikolai Teofilov wrote:
But something changed since 0.11 ...
In my application I have a master server and several slaves. Each slave pull
a document from the master, attach some data and push it back to the master
then this document can be updated from another slave and so on ... and this
works perfectly in 0.11. I was able to delete the document on the master
server with one single delete call.
Now each attachment on the slave will introduce a conflict so if I have
several attachments on some of the slave machines and if I want to delete
after that this document on the master database I have to delete each
document revision for each attachment and repeat this for each slave ...
Is there a way to delete the document with the whole history with a single
API call?
Thanks
Nikolai
On 12.09.2010, at 22:36, Klaus Trainer wrote:
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
...when you do what?
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this
situation?
The point is that when using the _bulk_docs API and all_or_nothing:
true, documents are written even if the given _rev number doesn't match
the current one. In that case (_rev number doesn't match), you get a new
conflict.
- Klaus
On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
Hi Klaus,
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this
situation?
Cheers
Nikolai
On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908535#action_12908535
]
Klaus Trainer commented on COUCHDB-885:
---
Note that the procedure I've previously described will create a conflict:
curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
{_id:doc,_rev:3-b06fcd1c1c9e0ec7c480ee8aa467bf3b,foo:bar,_conflicts:[1-4c6114c65e295552ab1019e2b046b10e]}
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database test on a remote couchdb server that reside on a
different machine!
2. Create new document: http://remote-server:5984/test/doc;
3. Create database test on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test -
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test -
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on
remote database.
This operation will delete the last revision of the document (after
the replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two
different couchdb servers, and only for documents that were updated with
a new attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COUCHDB-885) Delete document with attachment fails after replication.
Thanks Klaus,
It is somewhat inconvenient way compare to 0.11 single call, but it works!
I still cannot understand why adding a new field to the document with Futon
does not introduce a conflict but attaching a file does?
Cheers
Nikolai
On 13.09.2010, at 00:00, Klaus Trainer wrote:
You could take all the revs from the _conflicts list, and delete them
with one _bulk_docs call, e.g.:
curl -vX POST http://127.0.0.1:5984/foobase/_bulk_docs -H 'Content-Type:
application/json' -d '{all_or_nothing: true, docs:[{_id:doc,
_rev:2-818ecad858044ee3bb6017e938e98411, _deleted:true},
{_id:doc, _rev:2-3bf9067dce5f550d9bfcdab1217045e7,
_deleted:true}, {_id:doc,
_rev:2-13839535feb250d3d8290998b8af17c3, _deleted:true}]}'
- Klaus
On Sun, 2010-09-12 at 23:18 +0200, Nikolai Teofilov wrote:
But something changed since 0.11 ...
In my application I have a master server and several slaves. Each slave pull
a document from the master, attach some data and push it back to the master
then this document can be updated from another slave and so on ... and this
works perfectly in 0.11. I was able to delete the document on the master
server with one single delete call.
Now each attachment on the slave will introduce a conflict so if I have
several attachments on some of the slave machines and if I want to delete
after that this document on the master database I have to delete each
document revision for each attachment and repeat this for each slave ...
Is there a way to delete the document with the whole history with a single
API call?
Thanks
Nikolai
On 12.09.2010, at 22:36, Klaus Trainer wrote:
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
...when you do what?
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this
situation?
The point is that when using the _bulk_docs API and all_or_nothing:
true, documents are written even if the given _rev number doesn't match
the current one. In that case (_rev number doesn't match), you get a new
conflict.
- Klaus
On Sun, 2010-09-12 at 22:19 +0200, Nikolai Teofilov wrote:
Hi Klaus,
Correct me if I am wrong but there should be message like after the DELETE
operation:
{error:conflict,reason:Document update conflict.}
but I get:
{ok:true,id:doc,rev:3-9ac5f6d05704bf0b5e427d5b6ce7fc92}
Furthermore I don't understand where does the conflict comes in this
situation?
Cheers
Nikolai
On 12.09.2010, at 21:27, Klaus Trainer (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908535#action_12908535
]
Klaus Trainer commented on COUCHDB-885:
---
Note that the procedure I've previously described will create a conflict:
curl -X GET http://127.0.0.1:5984/foobase/doc?conflicts=true
{_id:doc,_rev:3-b06fcd1c1c9e0ec7c480ee8aa467bf3b,foo:bar,_conflicts:[1-4c6114c65e295552ab1019e2b046b10e]}
Delete document with attachment fails after replication.
Key: COUCHDB-885
URL: https://issues.apache.org/jira/browse/COUCHDB-885
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.1
Environment: Mac OSX, Windows XP, Windows 7
Reporter: Nikolai Teofilov
Step to reproduce the bug:
1. Make database test on a remote couchdb server that reside on a
different machine!
2. Create new document: http://remote-server:5984/test/doc;
3. Create database test on the local couchdb server.
4. Trigger pull replication http://remote-server:5984/test -
http://localhost:5984/test
5. Attach a file to the replicated document on the local couchdb server.
6. Trigger push replication http://localhost:5984/test -
http://remote-server:5984/test
7. Delete the replicated document that contain now the attachment on
remote database.
This operation will delete the last revision of the document (after
the replication) but the previous revision of the document (before the
replication) still exist in the database.
This defect appears only for replications between databases on two
different couchdb servers, and only for documents that were updated with
a new attachment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
