Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of cvollet@gmail.com designates
 209.85.210.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=E+ptBCnyDnJ6qMcGnvxKdKPTO5kig0Lv2DslCmfbdSFWp+jpThKFiiwP0K7zelV5iC
         OOrtWgLDD4SXK9WPlTuuI9YK5sgJDs9BJCu0PGtRFLjHmwc4bJtfYLKN7jXtWPbogWvH
         Lsnk0Be9lCwjkXMtKME1IfXsoRAhUF8SjgCnk=
Message-ID: <4DB0AD60.4030905@gmail.com>
Date: Thu, 21 Apr 2011 15:19:12 -0700
From: =?windows-1252?Q?Cl=E9ment_Vollet?= <cvollet@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Help needed: is couchDB a good fit for my app?
References: <4DAF1BE0.5070104@gmail.com>
	<BANLkTimuEakQG61CnN6fUYD=ksVYCO1BDA@mail.gmail.com>
	<4DB06C48.3010306@gmail.com>
	<BANLkTimVFiP+W0mFziTDibXM10j6ivuvBg@mail.gmail.com>
 <BANLkTikoZqbLiqC9oyN_WCG4tJgtBNF10Q@mail.gmail.com>
In-Reply-To: <BANLkTikoZqbLiqC9oyN_WCG4tJgtBNF10Q@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

Le 21/04/2011 12:09, Sean Copenhaver a �crit :
> 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 using
> show and list functions. I believe you could user the user's context/session
> 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.
>
Hum, that may be another option yes. Thanks, that provides me with
another argument to convince my boss to use CouchDB (which seems, quite
frankly, awesome).
> On Thu, Apr 21, 2011 at 2:23 PM, Ryan Ramage <ryan.ramage@gmail.com> 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
>>
>
>