couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1649) deleted documents reappear when _revs_limit reached when running replication
Date Wed, 16 Jan 2013 15:36:12 GMT

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

Robert Newson commented on COUCHDB-1649:
----------------------------------------

related to COUCHDB-1415?
                
> deleted documents reappear when _revs_limit reached when running replication
> ----------------------------------------------------------------------------
>
>                 Key: COUCHDB-1649
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1649
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>            Reporter: Ian Ward
>
> When the number of allowed revisions for a document as determined by _revs_limit is surpassed,
the document can be deleted but will then reappear as undeleted.  The following steps show
this behavior:
> - Create two databases, "A" and "B"
> - Set _revs_limit on both databases to 3
> - Create a document "foo" on database "A" (creates rev 1)
> - Edit and save the document (creates rev 2)
> - Edit and save the document again (creates rev 3)
> - Edit and save the document again (creates rev 4)
> - Run replication (non continuous, for testing purposes), replicating database "A" to
"B"
> - Delete document "foo" on database "A" (creates rev 5.  We're now two revs over the
_revs_limit, though we could be just 1 rev over and this problem will occur as well)
> - Replicate from A to B.  Replicate from B to A.
> You should now see that document "foo" appears on both databases, not deleted, and has
the original revision number.  What I expected is that the document would remain in a deleted
state, since the newest/latest revision before the last step where both databases replicate
is the "deleted" revision.
> I've tested that this occurs on versions 1.1 and 1.2.  1.1 on Ubuntu Precise using couchbase
deb, 1.2 on Ubuntu Quantal using core package.  Here is a bash script and sample output which
shows the behavior https://gist.github.com/81143d6919b26fe1f81e

--
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

Mime
View raw message