Nice. Miroslav
> On Feb 1, 2017, at 18:00, ermouth <[email protected]> wrote: > > 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
