couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-892) Method for restarting filtered replication
Date Sat, 25 Sep 2010 10:40:32 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914804#action_12914804
] 

Robert Newson commented on COUCHDB-892:
---------------------------------------

I'm surprised we don't already include "the entire string of the filter function ... to calculate
the replication ID", which sounds like the better fix and aligns with the way views are named.

The problem here is that the target database's checkpoint would depend on state of the source
database? Is the concern that this has security implications? The replicator, if started at
the target end, would be required to read the filter of the ddoc, replicate changes, and abort
if the ddoc changes during the replication.

adding start_seq is simpler but including the function in the MD5 calculation sounds more
correct.

> Method for restarting filtered replication
> ------------------------------------------
>
>                 Key: COUCHDB-892
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-892
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: Replication
>            Reporter: Marco Monteiro
>            Assignee: Filipe Manana
>            Priority: Minor
>
> I'm using filtered replication to maitain a database that has a subset of the documents
of some other database.
> The problem I have is when I change the filter. If the filter allows for more documents
to be replicated, those that
> were created before the last replication are not replicated. So, I have to remove the
database and recreate it.
> I see two solutions that can be implemented to help in this situation. The first one
is for the filtered replication
> to restart whenever the filter changes (maybe also adding an argument to replicate to
tell that" we want this to happen).
> Another solution is to add an argument to replicate ("start_seq", as sugested by fdmanana
on IRC) that would be the 
> source database ""local_seq that we want the replication to start from. This an be set
to 1 to restart from first change.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message