You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2017/04/06 16:17:41 UTC

[jira] [Commented] (COUCHDB-3255) Conflicts introduced by recreating docs with attachments

    [ https://issues.apache.org/jira/browse/COUCHDB-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15959213#comment-15959213 ] 

ASF subversion and git services commented on COUCHDB-3255:
----------------------------------------------------------

Commit 4b4238718c0a2dbf02cc00f6a855ff8ff8d5cd59 in couchdb-couch's branch refs/heads/COUCHDB-3287-pluggable-storage-engines from [~paul.joseph.davis]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=4b42387 ]

Ensure deterministic revisions for attachments

This re-fixes a corner case when recreating a document with an
attachment in a single multipart request. Since we don't detect that we
need a new revision until after the document has been serialized we need
to be able to deserialize the body so that we can generate the same
revisions regardless of the contents of the database. If we don't do
this then we end up including information from the position of the
attachment on disk in the revision calculation which can introduce
branches in the revision tree.

I've left this as a separate commit from the pluggable storage engine
work so that its called out clearly for us to revisit.

COUCHDB-3255


> Conflicts introduced by recreating docs with attachments
> --------------------------------------------------------
>
>                 Key: COUCHDB-3255
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-3255
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>            Reporter: Paul Joseph Davis
>
> When a document is re-created with an attachment it receives a non-deterministic revision.  This is due to a fairly old commit [1] that introduced the behavior by accidentally including information about revisions on disk into the revision id calculation when the revision id was being calculated by couch_db_updater when it realized that the update was re-creating a document that was previously deleted.
> I'm opening a PR with the fix.
> [1] https://github.com/apache/couchdb-couch/commit/08a94d582cd3086ebcbd51ad8ac98ca6df98a1b7



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)