From user-return-15931-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Apr 21 19:09:58 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8EAA32CC8 for ; Thu, 21 Apr 2011 19:09:58 +0000 (UTC) Received: (qmail 22148 invoked by uid 500); 21 Apr 2011 19:09:57 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 22018 invoked by uid 500); 21 Apr 2011 19:09:57 -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 22010 invoked by uid 99); 21 Apr 2011 19:09:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Apr 2011 19:09:57 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sean.copenhaver@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Apr 2011 19:09:50 +0000 Received: by vxk12 with SMTP id 12so54142vxk.11 for ; Thu, 21 Apr 2011 12:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vLHgIFnJbKWJnSgi8CbccghxQdGmIZAlpzoxB2sZHg0=; b=GD82Oe9rjreaZp6ldLz2XGpUavHT+0e85Wpmv1SjappZg6oxielPxaXPBaonqPjmuQ bOGD64i1/eKS9/mA2/EjjNT+q0LXNByBRcWhsQrXnNH6VohFeYUU6EFsrk9+VDiqTatg zsCMIAO2PlECLmTyaklJiykDS/kdPH7ne1AF0= 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=RgClcHMftltRhb6mv4Ab9d+iL/aC5TF28SvoJOGJ/tVlDBUP05ot3qQm9Vzkd/q/ac EYUiAdeT8Rdq+tOVu/Zlqur7b61t+8/0VwlQjv/okOuBT0Sodoyt0ME9WDOIqKX8J6Gv 03uEQ0f31vS0QohKHGpyFJcQtuX1+Qnfi7KmE= MIME-Version: 1.0 Received: by 10.52.76.193 with SMTP id m1mr432210vdw.204.1303412969554; Thu, 21 Apr 2011 12:09:29 -0700 (PDT) Received: by 10.52.169.161 with HTTP; Thu, 21 Apr 2011 12:09:29 -0700 (PDT) In-Reply-To: References: <4DAF1BE0.5070104@gmail.com> <4DB06C48.3010306@gmail.com> Date: Thu, 21 Apr 2011 15:09:29 -0400 Message-ID: Subject: Re: Help needed: is couchDB a good fit for my app? From: Sean Copenhaver To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=bcaec501603b0bc22504a1727bd5 --bcaec501603b0bc22504a1727bd5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Not saying that a database per user isn't a good idea (probably would work pretty well with the future replication database feature), but some alternatives that I could think of are: You could potentially have something in front of couchdb to restrict the access to regular doc GET/POST/PUT and force the outside world to pull usin= g show and list functions. I believe you could user the user's context/sessio= n object that is in the request object (pretty sure show/list get it) to filter out the non-user/public data. You'll probably have to always use update functions as well to avoid overriding tags. That or perhaps have the generic document stand alone and then the user specific stuff in a separate document owned by the user. I believe still in this scenario you would have to put something in front of couchdb to restrict access if they are private. You would be able to make use of filters for replication and changes pretty effectively I think. On Thu, Apr 21, 2011 at 2:23 PM, Ryan Ramage wrote: > >> You might want some architecture like this: > >> > >> [] Public Docs db | > >> | <----- hosted > >> [] User 1db [] User 2 db [].... | > >> ------------------------------------------------------ > >> > >> [] User1 phone db [] User 2 Phonedb [].... > >> > >> Then have replication between phone and user db. Then have replication > >> from Userdb to public docs db with a filter to take out private > >> tags... > >> > > > > Hum, something like that could yes. But I have a question regarding the > > stats. First, a tag can only take a value in a predefined set of value > > for that tag. So, is it possible that instead of filtering the tag > > completely, I update the stat of the value accordingly (+1 if the value > > has been chosen by the user, -1 if the user changed to another value or > > reset the tag)? > > CouchDB filtering is currently a yes/no operation per doc. So you > would want to have related docs to the tag that hold the 'stat of the > value'. Filter the parent tag doc, and let the 'stat of the value' > docs go back to the public db. > > > > > Oh, and also, I read that there is a limit depending on the OS for the > > number of concurrent databases. Won't that be a problem if there is a > > lot of users (which will hopefully be the case;)? > > Yes, there will be a limit on how many for concurrent dbs per OS. It > is really high anyway. Someone else will have to give real life > numbers on this. But if you hit the wall, just add more servers. They > are cheap as chips :) The couch replication model is nice because it > is flexible with how you might grow. > > Ryan > --=20 =93The limits of language are the limits of one's world. =93 -Ludwig von Wittgenstein --bcaec501603b0bc22504a1727bd5--