After long thoughts and some discussions around the CouchConf, I came up with the following solution:
own DBs for shared documents. IN DETAIL: The app I need this for is minutes.io, there are meetings and meetings have minutes which are separated documents for conflict and performance reasons. As I mentioned before, each user has an own database and listens to its _changes feed for live updates. If a user decides to share a document (incl. its minutes), he can share a secret url. The first time another user accesses this URL, a new DB gets created for the meeting and its minutes and two both side replications to the owner and the accessor dbs. If another user accesses the shared link, another both side replication gets initiated. This way, each user can make changes to the meeting document and add/remove/change minute documents of the particular meeting, and the changes get replicated for each user. I've no production experience with this setup yet, I'm still implementing it, but it's the best solution I came up with. I hope this insight helps anybody or in case you have any feedback, it's very welcome of course. – Gregor On Mon, Nov 7, 2011 at 4:06 AM, Adam Kocoloski <[email protected]> wrote: > On Nov 6, 2011, at 8:19 PM, Dave Cottlehuber wrote: > > > On 6 November 2011 14:14, Gregor Martynus <[email protected]> wrote: > >> *SCENARIO*: > >> > >> 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 https://github.com/hookio/couch > > for example) and when the required docs turn up, call the replicator > > to retrieve it. > > > > A+ > > Dave > >
