Reputation: 8971
There is an excellent article here (https://momentum.spindance.com/2016/02/couchdb-replications/) with useful information on CouchDB replication. And looking at the documentation it is easy to find reference to replication filters (e.g. http://docs.couchdb.org/en/1.6.1/couchapp/ddocs.html).
However they all seem to involve filtering what the changes feed will emit. I would like a master CouchDB to emit all the docs, and then several slaves to only store the docs that fit within their ID range.
Is it possible to do this with a filter in a design document?
Otherwise could this be done with a validate document update function on the slaves and a push replication on the master?
Slaves and master is actually misleading, as info will be inserted into the 'slaves' each of which needs to have a subset of info.
Upvotes: 2
Views: 1232
Reputation: 27971
The documentation for this doesn't seem to have made it across to the new wiki, but yes, you can do Named Document Replication by providing a doc_ids
attribute in your replication document.
Sorry, I realized I didn't answer your core question. No, you can't have the filter on the receiver. Filtering is done on the whole doc, so even if you could Couch would require all the full docs on the receiver before it could filter them anyway, so you'd be transferring all the documents even if you were able to do this.
You can, btw, just have a second DB on the receiver that replicates all the docs from the master, and then have it define the filter for your filtered replication to your other DB on the receiver.
...and yes, for Named Document Replication you have to provide all IDs, and no, there's no limit to the size of that data.
One other thing that you might not have thought of, the filter function is just part of a design doc, and all docs (including design docs) can be replicated. So you can actually create the filter on the receivers if you wish, and then replicate them up to the master, and then use them from the receiver in filtered replication.
Upvotes: 1