[ https://issues.apache.org/jira/browse/COUCHDB-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16012950#comment-16012950 ]
Joan Touzet commented on COUCHDB-3418: -------------------------------------- Hi Paul, This is expected. Database compression means that only the most recent revision required to successfully replicate the database is present. In the case of a deleted document, that means that only the "tombstone" (document ID + revision + "_deleted": true) is retained. This is done so that if the document is re-created later (with a revision 1 greater than the previous revision) we can successfully detect that this newer revision isn't, for instance, the original revision of that document. This is the same for all documents - older revisions will be cleaned away during database compression. Example: Doc is created (rev 1), modified 2 times (revs 2 and 3), and deleted (rev 4). You replicate and only see the rev 4 tombstone. Later, someone else also replicates, but re-creates a new version of that document (rev 5). You replicate with that person later and retrieve the newer version of the document (the re-created rev 5). Does this make sense? > _changes returns a single item that says a doc is deleted > --------------------------------------------------------- > > Key: COUCHDB-3418 > URL: https://issues.apache.org/jira/browse/COUCHDB-3418 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface > Reporter: Paul Kuruvilla > > I discovered this while working on maintaining a replica of the npm registry > (https://replicate.npmjs.com) for Gratipay (https://gratipay.com). > When I hit the {{/registry/_changes}} endpoint with a filter for {{doc_id = > 'adam-test'}}, I get back a single change which says that the doc was > deleted. This looks like a bug, because I'd expect that every 'deleted' > change would have a corresponding change for when the doc was created. > (Please correct me if my understanding is wrong) > Here is a cURL command to replicate the issue: > {code} > curl -XPOST -H "Content-Type: application/json" > https://replicate.npmjs.com/registry/_changes\?limit\=10\&filter\=_doc_ids -d > '{"doc_ids": ["adam-test"]}' > {code} > The output I receive is: > {code} > { > "results": [ > {"seq":1908160,"id":"adam-test","changes":[{"rev":"2-a543a8082c03a641a098fbe39e58afed"}],"deleted":true} > ], > "last_seq":1916520 > } > {code} > This was the first such occurrence we hit in the ~ 4 million changes that > we've processed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)