couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Filtered replication for design documents
Date Fri, 12 Apr 2013 07:22:50 GMT
On 12 April 2013 00:54, Michael Parker <> wrote:
> Hi all,
> I have two servers A and B, where A is running continuous pull replication
> against B, so any changes on B are propagated to A. Both have the same
> design documents.
> Say I push a new design document to A that modifies some views. After doing
> this, what I'd like to do is begin replicating data from A to B, so that
> any changes on A are propagated to B. I do not, however, want the updated
> design document on A to propagate to B, because B is serving live traffic
> and all requests will fail while it rebuilds its indices.
> If I include in my updated design document on A the following filter:
> function(doc, req) {
>   return "_design/" !== doc._id.substr(0, 8);
> }
> and begin on server A continuous _push_ replication to B, will I ensure
> that the updated design document is not propagated to B, because A is the
> source and contains the filter? (Actually, if I were to begin on server B
> continuous pull replication against A, then the design doc would also not
> be propagated, because also in this case A is again the source and the
> replication filter of the source is always used?)
> Thanks,
> Mike

You could cheat and replicate without admin privileges; the
destination ddocs then can't be written. This avoids needing a filter
at all.

Another trick is to deploy the changed ddoc under a different name to
the destination server (best to use a couchapp-type push probably for
this) and then trigger a rebuild on that when suitable. Then you can
swap the view names over when the view is built, and as the views are
referenced on disk by the md5 of the functions involved
(show/list/view/..) there will be no view rebuilding downtime. More
info in


View raw message