There is known feature of continuous filtered replication: until
replication restarts, filter function is frozen.
It means you can start continuous filtered replication using _replicator
DB, then change (or even remove) filter function – and have your sync still
running with an old filter.
To ensure your changed filter can take control, you must explicitly remove
and re-create _replicator doc. It means stop/restart of sync flow and bit
too complex.
There exist another way.
Imagine we have filter fn, distributing docs between nodes according to
some topology. Let‘s say our topology is just a branch of a filter design
doc, and accessible from inside filter fn as this.topology property.
So our ddoc looks like:
{_id:"_design/topo",
topology:{node1:["org1","org2"],node2:["org3"]},
filter:"function(doc, req){ /* whatever */}"}
What happens when we change topology property and save ddoc? Our already
running filter function is not hot-swapped, however it immediately receives
its updated parent ddoc as an input.
So filter fn takes new topology and persists it into this.topology
property. One step:
if (doc._id=="_design/topo") this.topology = doc.topology;
All subsequent changes will be processed with updated topology settings,
and we achieved this without touching _replication DB.
Works like a charm.
ermouth
