couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Dynamic Filtered Replication
Date Wed, 29 Aug 2018 08:13:37 GMT
changing the replicator doc _id will have no effect. As Nick has said, you need to change something
in the replication that is included in the checkpoint id calculations (it's derived from all
the parts of the replication settings that could change which documents are replicated. As
Nick also correctly says, this includes any filter code).

The simplest way to force a 'do over' is to delete the checkpoint documents (the _local document
that James refers to). CouchDB reads that document from both source and target and checks
if they match, so it should suffice to delete just one of them. Of course that does start
the replication from scratch. The Replicator won't actually write any document to the target
that already exists, but it will have to check the _rev of every document in the source database
against the target database. For small databases, this is no problem, but obviously it gets
worse as the database document count increases.

B.

> On 28 Aug 2018, at 16:09, Nick Vatamaniuc <vatamane@gmail.com> wrote:
> 
> Hi Andrea,
> 
> When replicating the content (source code) of the filter becomes part of
> the replication identity. If the filter changes the replication would get a
> new replication ID and it would effectively become a new replication and
> reprocesses all the changes.
> 
> Cheers,
> -Nick
> 
> 
> On Tue, Aug 28, 2018 at 8:51 AM Andrea Brancatelli <abrancatelli@schema31.it>
> wrote:
> 
>> Hello everybody.
>> 
>> I have a pretty academic question about CouchDB replication…
>> 
>> I’m working on creating a setup to test my idea but I thought asking could
>> save me some headaches.
>> 
>> This is the scenario.
>> 
>> Let’s suppose I have two database: Master and Slave with a Filtered
>> Replication that uses some information stored in the _user database to
>> determine wether to replicate the document or not …
>> 
>> Now we put 100 docs in the Master DB, so Master Update SEQ reaches, let’s
>> say, 100.
>> 
>> The filter has filtered the replicated documents and on the Slave DB we
>> have, let’s say 40 documents.
>> 
>> The condition in the _user database changes and the new condition would
>> mach 60 documents of the Master.
>> 
>> Is there an “easy” way to refresh the sincronization between the two
>> database and have the 20 missing docs synced?
>> 
>> Maybe resetting the replication would automagically fix this (like the
>> replication skipping the docs that are already in the Slave db?)
>> 
>> How would you handle such a situation? Especially when the amount of docs
>> is not 100... :-)
>> 
>> I hope my question is clear enough.
>> 
>> Thanks a lot.
>> 
>> -------
>> Andrea Brancatelli
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 


Mime
View raw message