couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Klein <st.fankl...@gmail.com>
Subject Re: The state of filtered replication
Date Wed, 25 May 2016 10:34:09 GMT
Hi Stefan,

2016-05-25 10:34 GMT+02:00 Stefan du Fresne <stefan@medicmobile.org>:

[ ... ]


> Ideally then, I would like to remove filter replication completely, but
> there does not seem to be a good alternative right now.
>
> Looking through the archives there was talk of adding view replication,
> see:
> https://mail-archives.apache.org/mod_mbox/couchdb-user/201307.mbox/%3CCAJNb-9pK4CVRHNwr83_DXCn%2B2_CZXgwDzbK3m_G2pdfWjSsFMA%40mail.gmail.com%3E
> <
> https://mail-archives.apache.org/mod_mbox/couchdb-user/201307.mbox/%3CCAJNb-9pK4CVRHNwr83_DXCn%2B2_CZXgwDzbK3m_G2pdfWjSsFMA%40mail.gmail.com%3E>
> , but it doesn't look like this ever got resolved.
>
> There is also often talk of databases per user being a good scaling
> strategy, but we're basically doing that already (with PouchDB),  and for
> us documents aren't owned / viewed by just one person so this does not get
> us away from filtered replication (eg a supervisor replicates her documents
> as well as N sub-users documents). There are potentially wild and crazy
> schemes that involves many different databases where the equivalent of
> filtering is expressed in replication relationships, but this would add a
> massive amount of complexity to our app, and I’m not even convinced it
> would work as there are lots of edge cases to consider.


[ ... ]

We ran into similar issues with the one db per user and filtered
replication.
I solved it a daemon listening to the main DB changes feed, determining to
which user(s) this changed document is to be replicated and using single
shot replications by documentID to actually get the document replicated.
So there is just one listener to the (in our case unfiltered) changes feed
and short replications by documentID.

For our case this works very well so far.

regards,
Stefan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message