incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joscha Feth <jos...@feth.com>
Subject Modeling question
Date Tue, 05 Jan 2010 17:26:34 GMT
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.

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


Mime
View raw message