couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: replicate A => B, but only docs that exist in B
Date Mon, 07 Nov 2011 03:06:29 GMT
On Nov 6, 2011, at 8:19 PM, Dave Cottlehuber wrote:

> On 6 November 2011 14:14, Gregor Martynus <> wrote:
>> Each user has its own DB ("B") of documents which replicates continuously
>> to a center DB ("A") which contains all documents from all users. That
>> works perfectly fine so far.
>> What I'd like to add now are "shared documents", which can be updated from
>> others in the center DB ("A"). This changes should be replicated back to
>> the owners DB ("B").
>> Hope that makes sense so far?
>> *IDEA*:
>> What I'd love to have would be as simple way where I could start a
>> continuous replication "A" => "B" which only replicates the docs that do
>> already exist in "B". Is there something like this?
> I think you mean, only replicate updated documents that already exist
> in B. No I don't think this is possible today directly within the
> replicator. But you can ask the replicator to pull or push a specific
> set of ids only.

Wouldn't it be possible to write a validator that rejects new document creations from a particular
user, then supply that user's credentials in the target specification for the replicator?

>> I though about making a filtered replication "A" => "B" where the filter
>> checks if the document exists in "B", but as far as I understand it, the
>> filter only has access to the doc from "A", not from "B", right?
>> *NOTE*:
>> I know I could use a filter that checks for some kind of `owner_id` in the
>> documents, but each document has child elements which I want to keep
>> atomic, and I do not want to add an `owner_id` attribute to all of these.
> What about:
> #1 client-driven pull.
> run an external process (perhaps from within couchdb itself) that
> queries localhost/b/_all_docs, then page through these (if needed),
> asking the replicator to retrieve just those specific docs. I assume
> you can set up a continuous replication with specific doc keys just as
> any normal replication request.
> #2 listen on changes feed.
> get a list of localhost/b/_all_docs, then pass this to your filtered
> changes feed (maybe event driven with
> for example) and when the required docs turn up, call the replicator
> to retrieve it.
> A+
> Dave

View raw message