incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregor Martynus <gre...@martynus.net>
Subject Re: replicate A => B, but only docs that exist in B
Date Thu, 10 Nov 2011 09:47:13 GMT
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 <kocolosk@apache.org> wrote:

> On Nov 6, 2011, at 8:19 PM, Dave Cottlehuber wrote:
>
> > On 6 November 2011 14:14, Gregor Martynus <gregor@martynus.net> 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
>
>

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