Hey Stefan, That sounds really interesting!
So to be clear, this is effectively replacing replication— where the client negotiates with the server for a collection of changes to download— with a daemon that builds up a collection of documents that each client should get (and also presumably delete), which clients can then query for when they’re able? This is sort of like ‘compiling’ the replication result so you know the answer when the client asks, as opposed to working it out live each time? Cheers, Stefan > On 25 May 2016, at 11:34, Stefan Klein <[email protected]> wrote: > > Hi Stefan, > > 2016-05-25 10:34 GMT+02:00 Stefan du Fresne <[email protected]>: > > [ ... ] > > >> 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
