You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Colin Coghill (JIRA)" <ji...@apache.org> on 2012/07/31 23:46:34 UTC
[jira] [Created] (COUCHDB-1518) HTTP COPY with attachments can
leave the "revpos" of attachments higher than the "_rev" of the document
Colin Coghill created COUCHDB-1518:
--------------------------------------
Summary: HTTP COPY with attachments can leave the "revpos" of attachments higher than the "_rev" of the document
Key: COUCHDB-1518
URL: https://issues.apache.org/jira/browse/COUCHDB-1518
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.2, 1.1.1
Environment: Debian Linux 6.0.5 / CouchDB 1.1.1 / Erlang R14B03
Ubuntu Linux 12.04 / CouchDB 1.2.0 / Erlang R15B01
Reporter: Colin Coghill
When COPYing a document with attachments, the _rev of the new document is set to 1-something, but the revpos on the attachments is left as is, meaning they're generally higher than the _rev of the new document.
I believe this is incorrect, and will cause problems later when updating/replicating the document. (I believe I'm seeing specific problems and am working on a test case, but am not sure they're particularly necessary if this behaviour is incorrect)
It's quite possible I've misunderstood how attachment revpos works and that this behaviour is ok.
Specific naming IDs, attachments, etc, don't seem to matter, substitute your own.
Untested on earlier versions of CouchDB.
curl -X PUT http://127.0.0.1:5984/testdb/document1 -d '{"name": "cat pictures"}'
curl -X GET http://127.0.0.1:5984/testdb/document1
# Note down REV and put it in the attachment upload:
curl -X PUT http://127.0.0.1:5984/testdb/document1/cat1.jpg?rev=REV --data-binary @cat1.jpg -H 'Content-Type: image/jpeg'
# Copy the document
curl -X COPY http://127.0.0.1:5984/testdb/document1 -H "Destination: document2"
curl -X GET http://127.0.0.1:5984/testdb/document2
# Note: revision is 1-something
# revpos on attachment is 2-something
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1518) HTTP COPY with attachments can
leave the "revpos" of attachments higher than the "_rev" of the document
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428621#comment-13428621 ]
Robert Newson commented on COUCHDB-1518:
----------------------------------------
While it does look wrong to me (I think revpos should be reset to 1), it doesn't seem to cause any problems. I can add, delete attachments to the copied document, and replicate it successfully with all attachments intact.
I even managed to get this;
{"_id":"doc3","_rev":"3-776101d8f018bccc094ae4dd62d4365f","_attachments":{"bar.txt":{"content_type":"text/plain","revpos":3,"digest":"md5-wfW2M8/EmLx6SWAp6JUOWQ==","length":655,"stub":true},"foo.txt":{"content_type":"text/plain","revpos":2,"digest":"md5-P3lZhLztRM25ckMsiQSAQg==","length":1309,"stub":true},"baz.txt":{"content_type":"text/plain","revpos":3,"digest":"md5-1Z0aHUOBa9/a3yA6eou4GA==","length":6,"stub":true}}}
That's two different attachments with the same revpos.
> HTTP COPY with attachments can leave the "revpos" of attachments higher than the "_rev" of the document
> -------------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-1518
> URL: https://issues.apache.org/jira/browse/COUCHDB-1518
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 1.1.1, 1.2
> Environment: Debian Linux 6.0.5 / CouchDB 1.1.1 / Erlang R14B03
> Ubuntu Linux 12.04 / CouchDB 1.2.0 / Erlang R15B01
> Reporter: Colin Coghill
> Assignee: Robert Newson
>
> When COPYing a document with attachments, the _rev of the new document is set to 1-something, but the revpos on the attachments is left as is, meaning they're generally higher than the _rev of the new document.
> I believe this is incorrect, and will cause problems later when updating/replicating the document. (I believe I'm seeing specific problems and am working on a test case, but am not sure they're particularly necessary if this behaviour is incorrect)
> It's quite possible I've misunderstood how attachment revpos works and that this behaviour is ok.
> Specific naming IDs, attachments, etc, don't seem to matter, substitute your own.
> Untested on earlier versions of CouchDB.
> curl -X PUT http://127.0.0.1:5984/testdb/document1 -d '{"name": "cat pictures"}'
> curl -X GET http://127.0.0.1:5984/testdb/document1
> # Note down REV and put it in the attachment upload:
> curl -X PUT http://127.0.0.1:5984/testdb/document1/cat1.jpg?rev=REV --data-binary @cat1.jpg -H 'Content-Type: image/jpeg'
> # Copy the document
> curl -X COPY http://127.0.0.1:5984/testdb/document1 -H "Destination: document2"
> curl -X GET http://127.0.0.1:5984/testdb/document2
> # Note: revision is 1-something
> # revpos on attachment is 2-something
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1518) HTTP COPY with attachments can
leave the "revpos" of attachments higher than the "_rev" of the document
Posted by "Robert Newson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Newson reassigned COUCHDB-1518:
--------------------------------------
Assignee: Robert Newson
> HTTP COPY with attachments can leave the "revpos" of attachments higher than the "_rev" of the document
> -------------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-1518
> URL: https://issues.apache.org/jira/browse/COUCHDB-1518
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 1.1.1, 1.2
> Environment: Debian Linux 6.0.5 / CouchDB 1.1.1 / Erlang R14B03
> Ubuntu Linux 12.04 / CouchDB 1.2.0 / Erlang R15B01
> Reporter: Colin Coghill
> Assignee: Robert Newson
>
> When COPYing a document with attachments, the _rev of the new document is set to 1-something, but the revpos on the attachments is left as is, meaning they're generally higher than the _rev of the new document.
> I believe this is incorrect, and will cause problems later when updating/replicating the document. (I believe I'm seeing specific problems and am working on a test case, but am not sure they're particularly necessary if this behaviour is incorrect)
> It's quite possible I've misunderstood how attachment revpos works and that this behaviour is ok.
> Specific naming IDs, attachments, etc, don't seem to matter, substitute your own.
> Untested on earlier versions of CouchDB.
> curl -X PUT http://127.0.0.1:5984/testdb/document1 -d '{"name": "cat pictures"}'
> curl -X GET http://127.0.0.1:5984/testdb/document1
> # Note down REV and put it in the attachment upload:
> curl -X PUT http://127.0.0.1:5984/testdb/document1/cat1.jpg?rev=REV --data-binary @cat1.jpg -H 'Content-Type: image/jpeg'
> # Copy the document
> curl -X COPY http://127.0.0.1:5984/testdb/document1 -H "Destination: document2"
> curl -X GET http://127.0.0.1:5984/testdb/document2
> # Note: revision is 1-something
> # revpos on attachment is 2-something
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1518) HTTP COPY with attachments can
leave the "revpos" of attachments higher than the "_rev" of the document
Posted by "Aaron Lisman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457480#comment-13457480 ]
Aaron Lisman commented on COUCHDB-1518:
---------------------------------------
TouchDB seems to care about this: https://github.com/couchbaselabs/TouchDB-iOS/blob/master/Source/TDDatabase%2BAttachments.m#L466
> HTTP COPY with attachments can leave the "revpos" of attachments higher than the "_rev" of the document
> -------------------------------------------------------------------------------------------------------
>
> Key: COUCHDB-1518
> URL: https://issues.apache.org/jira/browse/COUCHDB-1518
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
> Affects Versions: 1.1.1, 1.2
> Environment: Debian Linux 6.0.5 / CouchDB 1.1.1 / Erlang R14B03
> Ubuntu Linux 12.04 / CouchDB 1.2.0 / Erlang R15B01
> Reporter: Colin Coghill
> Assignee: Robert Newson
>
> When COPYing a document with attachments, the _rev of the new document is set to 1-something, but the revpos on the attachments is left as is, meaning they're generally higher than the _rev of the new document.
> I believe this is incorrect, and will cause problems later when updating/replicating the document. (I believe I'm seeing specific problems and am working on a test case, but am not sure they're particularly necessary if this behaviour is incorrect)
> It's quite possible I've misunderstood how attachment revpos works and that this behaviour is ok.
> Specific naming IDs, attachments, etc, don't seem to matter, substitute your own.
> Untested on earlier versions of CouchDB.
> curl -X PUT http://127.0.0.1:5984/testdb/document1 -d '{"name": "cat pictures"}'
> curl -X GET http://127.0.0.1:5984/testdb/document1
> # Note down REV and put it in the attachment upload:
> curl -X PUT http://127.0.0.1:5984/testdb/document1/cat1.jpg?rev=REV --data-binary @cat1.jpg -H 'Content-Type: image/jpeg'
> # Copy the document
> curl -X COPY http://127.0.0.1:5984/testdb/document1 -H "Destination: document2"
> curl -X GET http://127.0.0.1:5984/testdb/document2
> # Note: revision is 1-something
> # revpos on attachment is 2-something
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira