[
https://issues.apache.org/jira/browse/COUCHDB-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774392#comment-13774392
]
Jason Smith commented on COUCHDB-1893:
--------------------------------------
Thanks, Stéphane.
I like this. But I think, to a first approximation, this change would be
extremely difficult. It would change a lot of the internal CouchDB
architecture. In the general case, old_doc cannot be known. For example, if you
are replicating to a database, you might send a single update for a document
representing several revisions' worth of change. Usually CouchDB does not
support a feature unless it can be supported for all situations.
To me, this is an application-level decision. HTTP DELETE is identical to an
update with only the _id, _rev, _deleted fields. If it is important to your
application whether a document propagates to other databases based on its
content, then you should store that content, i.e. set _deleted=true with some
or all of the other fields intact. The validate_doc_update function can ensure
that this is done correctly and consistently.
> 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
