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:32:03 GMT

    [ 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

Mime
View raw message