2016-05-25 12:48 GMT+02:00 Stefan du Fresne <[email protected]>:
> 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? > Sorry, didn't describe well enough. On Serverside we have one big database containing all documents and one db for each user. The clients always replicate to and from their individual userdb, unfiltered. So the db for a user is a 1:1 copy of their pouchdb/... on their client. Initially we set up a filtered replication for each user from servers main database to the server copy of the users database. With this we ran into performance problems and sooner or later we probably would have ran into issues with open file descriptors. So what we do instead is listening to the changes of the main database and distribute the documents to the servers userdb, which then are synced with the clients. Note: this is only for documents the users actually work with (as in possibly modify), for queries on the data we query views on the main database. For the way back, we listen to the _dbchanges, so we get an event for changes on the users dbs, get that change from the users db and determine what to do with it. We do not replicate back users changes to the main database but rather have an internal API to evaluate all kinds of constrains on users input. If you do not have to check users input, you could certainly listen to _dbchanges and "blindly" one-shot replicate from the changed DB to your main DB. -- Stefan
