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 gcdcu-couchdb-user@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: user@couchdb.apache.org
From: Joscha Feth <joscha@feth.com>
Subject: Re: Modeling question
Date: Tue, 05 Jan 2010 19:44:51 +0100
Lines: 45
Message-ID: <hi01b3$f1c$1@ger.gmane.org>
References: <hhvsoa$uf2$1@ger.gmane.org>
	 <e282921e1001050949h12d61b10g33fe71bc7826cb10@mail.gmail.com>
	 <hhvup2$68n$1@ger.gmane.org>
 <e282921e1001051032q41d96b97s515463109e9fd098@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
In-Reply-To: <e282921e1001051032q41d96b97s515463109e9fd098@mail.gmail.com>
Sender: news <news@ger.gmane.org>

Hi Chris,

On 05.01.10 19:32, Chris Anderson wrote:
> If you store the full path (A, B) on the Cs as well, then you can collate like:
>
> A,
> A, B
> A, B, C
> A, B2
> A, B2, C
> A, B2, C2
>
> etc.
>
> If you are paginating through large directories, then you'll want to
> store the parent metadata in client state, so you don't have to reload
> it for each page.

I don't see how that can help when a user requests a C without knowing 
that it is a C and has a parent B and A. I still need to either allow 
access or deny it. I don't see how something like this is possible with 
CouchDB out of the box, as I don't have the ability to make another request.


> Without knowing more about the actual requirements, I can't argue this
> point, but I've seen my share of cases that were simplified greatly by
> moving to a key-value model. For instance, S3 has a per-bucket
> security model, which is very similar to CouchDB's planned
> per-database read control model.
>
> If you use a database-per-user (or group), quota calculations will
> become much easier (and more realistic, as they account for actual
> disk space used, not just total stored file size). You also get a
> bunch of other simplifications (like the ability to replicate data
> independently, also you don't have to worry so much about fine-grained
> access control.) CouchDB can handle millions of databases on a single
> node.

I can not use a database per user or group, as both are completely 
dynamic (e.g. a user may gain or loose access on some documents any 
time). But I could use a separate database for any A (and storing all 
B's and C's within it) - would that help? I can't see how currently...

regards,
Joscha