couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Smith (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1893) Allow replication filters to meaningfully apply to deleted documents
Date Mon, 23 Sep 2013 09:00:07 GMT

    [ 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

Mime
View raw message