incubator-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 17:49:13 GMT
On Tue, Jan 5, 2010 at 9:26 AM, Joscha Feth <> wrote:
> Hello List,
> the following scenario:
> CouchDB is used as storage for hierarchical data in three levels:
> * There are A's which are root elements
> * There are B's which belong to A's. Any B knows (id) its (one and only)
> parent A.
> * There are C's which belong to B's. Any C knows (id) its (one and only
> parent B and parent A).
> All of them (A's, B's and C's) may contain a simplified access list (user
> can read (1), user can write(2), user is not allowed to access the document
> (0), default).
> Now if a user has read access to an A, he can also read all B's and
> therefore also all C's belonging to that specific A.
> Now it could be the case that a user can read A, but has additional rights
> on a specific sub-element (may be either a B or a C).
> Users want to not only read/change A's only, but also B's and C's, not
> necessarily knowing the parenting A or B before the request.
> Now my question is: how can I enforce that type of access control.
> There are multiple possibilities which come on my mind, but all have a major
> drawback - I hope some of you guys have an idea.
> Possibility A)
> I create a view which contains all documents and create a list, which runs
> through all requested elements, checking whether the user has the access he
> wants. Drawback of this is, that I need to loop over *all* elements within
> CouchDB on *every* request, even if the user only wants to read a certain A,
> B or C until I found the requested element.
> This possibility actually sounds very bad from a performance perspective.

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.

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.

> Possibility B)
> I put some sort of middleware between the application and couchDB, which
> fetches the requested document, reads the belonging parents from CouchDB in
> a subsequent request and then decides whether to return the fetched
> document/do the change or not. Drawback here is the additional request and
> the need for buffering the first request until it can be decided whether to
> return it or not OR to make a third piped request when the user has the
> according rights.
> What I don't like here is, that not actually only writes are getting slower,
> but also the reads. And all reads to CouchDB triple (writes double).
> regards,
> Joscha

Chris Anderson

View raw message