Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 15297 invoked from network); 11 Nov 2009 05:00:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Nov 2009 05:00:26 -0000 Received: (qmail 26091 invoked by uid 500); 11 Nov 2009 05:00:25 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 25851 invoked by uid 500); 11 Nov 2009 05:00:23 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 25840 invoked by uid 99); 11 Nov 2009 05:00:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2009 05:00:22 +0000 X-ASF-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FS_REPLICA,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dnolen.lists@gmail.com designates 209.85.210.176 as permitted sender) Received: from [209.85.210.176] (HELO mail-yx0-f176.google.com) (209.85.210.176) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2009 05:00:19 +0000 Received: by yxe6 with SMTP id 6so735879yxe.13 for ; Tue, 10 Nov 2009 20:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=IwOkx1hjYmegSYShTCAaGk1t/LInlVuifJ3I2SBWNeQ=; b=S2KU0mwmyLqzgxLXHQRk5gyNkghQFL3fKBxiDsps1kq5X+s1z1RnZQ+7OnSKj9ixq1 n2dfJ4vhJQ3eQlHoHWjnb1a57102BsXbTxR+j4bH5IlBoVhpwG37eQM1VwzxmtNTRnmm PlbCvQU4pfJq8H3kNrVtpkhT9c08vAjMF59SM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=K+jtiiapgsDazVRYMXH19P6FOIej0U1bQ7P2ongOU4HFS9lJ7GG4OuHtKR1c+vfYGu IW3iqRfk/f2eKDVdoIpGWuYFhVjThYi2JAmkw37RL0QpDfzJ/XGyU8h0v8EcNrY0GOLa 9mXA1vmybvOMXIr68Rtu568b6mZwlVK2k/5XI= MIME-Version: 1.0 Received: by 10.101.138.19 with SMTP id q19mr1132418ann.99.1257915598533; Tue, 10 Nov 2009 20:59:58 -0800 (PST) In-Reply-To: <81d01c0911102042l5a05da76rc499b179e0cd98a5@mail.gmail.com> References: <81d01c0911102042l5a05da76rc499b179e0cd98a5@mail.gmail.com> Date: Tue, 10 Nov 2009 23:59:58 -0500 Message-ID: Subject: Re: Question about document copies & replication From: David Nolen To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e68ea0e36875b80478114cfa --0016e68ea0e36875b80478114cfa Content-Type: text/plain; charset=UTF-8 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 > 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 > > > --0016e68ea0e36875b80478114cfa--