couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nolen <dnolen.li...@gmail.com>
Subject Re: Question about document copies & replication
Date Wed, 11 Nov 2009 04:59:58 GMT
On Tue, Nov 10, 2009 at 11:42 PM, Christopher O'Connell <
jwriteclub@gmail.com> wrote:

> It might make more sense to store a field indicating whether a document is
> public or private, and then use some software to only replicate public
> docs.
>

?

"Some software" as in _not_ CouchDB?


> Keeping multiple local copies just seems like a bad plan, and if you want
> to
> support two way replications, it will almost certainly run into problems.
>

In my scenario the publish documents is always "upstream". Users have the
canonical copy so to speak. There will never be reason to replicate from the
remote server to a local user/public. The existance of a local user/public
is specifically to have a filtered list of the user's data that needs to
replicated to the remote server without having to reinvent the wheel (i.e.
write our software to handle this). Aslo, in our application the user might
not only use our server for sharing content. He/she may decide to use
another server - by having user/public, it's becomes trivial for them to
replicate their public documents to another service.


> Indeed, you may want to replicate the whole user database as it is, and
> simply expose the public documents via a view on the server: Something like
>

The point is actually to not replicate everything. user/private never gets
replicated to the server. That is, it's is truly _private_.


> function(doc) {
>    if(doc.Visibility == "Public")
>        emit(doc._id,);
> }
>
> Those who really know what they're talking about are welcome to slap me
> around on this.
>
> ~ Christopher
>
> On Tue, Nov 10, 2009 at 9:19 PM, David Nolen <dnolen.lists@gmail.com>
> wrote:
>
> > Ok,
> >
> > My mind is being blown by CouchDB :D
> >
> > So I've realized that having a few databases per user is a really great
> > idea
> > if you decide to scale by decentralizing your content (clients do the
> heavy
> > lifting by running queries on their local couchdb instances - since
> you're
> > replicating to the client you don't really care that a lot of data is
> > getting copied around). Every user has their own view of the world, and
> the
> > server CouchDB instance is really only for dealing with content shared
> > between users.
> >
> > In our application (http://shiftspace.org), I'm thinking something along
> > these lines:
> >
> > Client's laptop CouchDB instance:
> > user/private - all the documents a user has created plus replicated
> content
> > from groups and whatnot
> > user/public - all the user's public content
> > user/inbox - short messages
> >
> > Server CouchDB instance:
> > group/x - group dbs of shared content. Replicated downstream to
> individual
> > user/private who belong to the group
> > master - user/public dbs replicated upstream to here.
> >
> > So my question is this. When a user publishes a document, it is written
> to
> > user/private. If the user publishes a document to the world, we make a
> copy
> > of it in user/public - it's just the same data minus the _rev field.
> > Whenever a user updates a public document, we update the user/private
> copy
> > as well as the the user/public copy which will be replicated upstream to
> > the
> > server.
> >
> > So my question for the CouchDB gurus, will creating copies of documents
> in
> > this manner create potential problems?
> >
> > Thanks much,
> > David
> >
>

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