couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <d...@muse.net.nz>
Subject Re: Filtered Replication Question
Date Mon, 18 Jun 2012 09:06:56 GMT
On 18 June 2012 00:31, bsquared <bwcode4u@gmail.com> wrote:
> Hello,
>
> I am wondering how to implement a filtered replication with a blacklist
> of sorts.
>
>
> (C..?) <--> (B?) <--> (A)
>
> Where (A) is a local couchapp and (B) is an optional duplicate on the
> Internet.  A and B replicate with one or more document stores (C..Z).  I
> want to be able to ignore selected documents from the document
> stores. The net affect is that user of (A) is deleting the document from
> their replicated copies, but it still exists on the original document
> store.
>
> The idea that comes to mind for me is to have a design doc hold some
> document metadata that I could use in a filter.
>
>         my_doc_metadata : [
>                         {id: doc_1, state:hidden
>                         {id: doc_2, state:pinned}, ...]
>
> This doc would be replicated between (A) and (B) only.
>
> Is this possible?  If so how could this be implemented in a filter?
>
> Any alternatives come to mind?
>
> Thank you.
>
> --
> Regards,
> Brian
>

As Mark says, replication and many other operations in CouchDB
are per-doc only by design.

You should assume that eventually all documents will end up
replicating to all nodes, and plan filters/views/replication/changes
feeds with that in mind. Even if you think you can avoid it, still
plan for the situation when it *does* happen. Experience shows
this is the better strategy.

Having said that;

You can always replicate selected documents with filtered replication
as Mark proposes, or pass an array of keys of docs you want.

Therefore its possible but not necessarily efficient to store a blacklist
document or views listing those ids, retrieve that and then only replicate
the remainder of (all_docs ids - blacklist). Whether this is efficient or
not will largely depend on bandwidth and the number of documents in
each set.

Finally, if the state of a document might change from pinned/hidden
then neither my nor Mark's approach will be sufficient to "delete" docs
on node B after their state has changed on node A.

A+
Dave

Mime
View raw message