[
https://issues.apache.org/jira/browse/COUCHDB-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774418#comment-13774418
]
Jason Smith commented on COUCHDB-1893:
--------------------------------------
Note, compaction is not the only thing that breaks. I might bring my couch
online after weeks in the field, and it will replicate back to you. Each
document could have hundreds of changes, ninety-nine of which will be lost. So
when you replicate those changes further downstream, what would the value of
old_doc?
And in general, anybody can update any document to have any revision history
they want using the ?new_edits=false option.
> Allow replication filters to meaningfully apply to deleted documents
> --------------------------------------------------------------------
>
> Key: COUCHDB-1893
> URL: https://issues.apache.org/jira/browse/COUCHDB-1893
> Project: CouchDB
> Issue Type: Improvement
> Components: JavaScript View Server
> Reporter: Stéphane Alnet
>
> A document that is deleted using the DELETE command will be presented to a
> replication filter as an empty record with only a `_deleted:true` field. A
> replication filter can then only use the document ID to decide whether or not
> to propagate the deletion; in most cases this is not sufficient, and one may
> have to pass along deletion documents for IDs that would not have been
> replicated by the filter.
> This might lead to document IDs being leaked to the target database, which
> might be undesirable; more importantly if the goal of filtering was to build
> a smaller subset of the source database (for example to replicate a very
> large database to a device that has smaller storage space), those deletion
> documents might overfill the database (they never get compacted).
> I had somewhat documented this issue on the Wiki
> (http://wiki.apache.org/couchdb/Replication#Filtered_Replication) a while
> back but never got to add it to JIRA.
> Dave Cottlehuber on the PouchDB list suggested to use PUT with a
> `_deleted:true` field to work around the problem (the PUT body can then
> contain data sufficient to enable the filter to work). However we're still
> stuck in case DELETE was used instead.
> My suggestion is to expand the replication filter API to add an optional
> third argument
> filter(doc,req,old_doc)
> where old_doc if present references the version of the document that will get
> deleted. It is then up to the filter to use the _deleted flag in `doc` and
> the values in `old_doc`.
> (It might be useful/meaningful/easier to add old_doc in all cases; at this
> point I'm only suggesting to add it in the case doc contains a _deleted
> field.)
--
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
