couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Modeling question
Date Tue, 05 Jan 2010 18:32:05 GMT
On Tue, Jan 5, 2010 at 10:01 AM, Joscha Feth <> wrote:
> On 05.01.10 18:49, Chris Anderson wrote:
>> if you collate correctly and use startkey and endkey you will be be
>> able to read just the relevant rows from the view. This should be
>> practically instantaneous, so it's probably the right solution.
> Actually this is only true for A's (I do this already), as any B or C does
> not necessarily have its own access field.
> As it is not possible to temporary store variables in a map function, there
> is no way I can distribute the acl from a parent element (such as A or B)
> into a child element (B or C).
> I could misuse reduce probably, but as this is discouraged, I did not even
> try.
> Also an A does not have any information about its children, so when emitting
> an A (which will most likely contain the access information), I can not also
> emit that information for any child (B or C).
> This makes using starkey and endkey only suitable for A's but not for any
> child element in the hierarchy.

If you store the full path (A, B) on the Cs as well, then you can collate like:

A, B
A, B, C
A, B2
A, B2, C
A, B2, C2


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.

> Any other ideas?
>> I mentioned before, but I'll mention again - if there's a way to
>> achieve your business case without modeling a hierarchy (always an
>> impedance mismatch with key value stores) you will simplify a lot of
>> things. Not that it's impossible to do a hierarchy, but if you can get
>> away without it, you'll have a lot less on your plate.
> I've read that multiple times, but you know there are these times when a
> hierarchy just is needed.

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


> regards,
> Joscha

Chris Anderson

View raw message