couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Limiting views to special users
Date Tue, 29 Dec 2009 17:49:34 GMT
On Mon, Dec 28, 2009 at 11:59:02AM +0000, Joscha Feth wrote:
> I am using couchdb to store hierarchical data - one of the documents of
> this hierarchy contains some information about users being allowed to
> access the data (e.g. a user name which has access).
> Now the problem is: I can not just obey emitting the documents within
> my view, as there is no information in the majority of documents - so
> my idea was to raise an exception as soon as I see the document
> containg the credentials and the user *not* having access.

But if you are talking about *view* map functions, this makes no sense to
me. The view is a data structure, which is built independently of the person
trying to access it (and conversely, if multiple people try to access the
view, they will all have the same access to it, because the view has already
been built)

If you are talking about a *list* function, then this can change its output
depending on the user making the requeset.

> You can try this behaviour with a simplified temporary view:
> function(doc) {
>   if(Math.random() > 0.7) {
>     throw({forbidden : "Buh!"});
>   }
>   emit(null, doc);
> }

This violates the essential pre-requistite of a map function, that it must
be deterministic and depend only on the input document. Otherwise,
incremental building of map-reduce could not work.

> Now it seems to work fine generally, but there are three things which
> worry me:
> * the map function still seems to be run on documents even after the
> exception has been thrown (which is unnecessary).

The map function will be run on *all* documents. That is the purpose of the
map function. Whenever you (a) add, or (b) update a document, those new or
updated documents are always passed to the map function.

> * the results of the view seem to be cached, even though Math.random()
> may change at each invocation - is this something specific to the
> temporary views (I used this for testing) or is this the default
> behaviour?

Views are permanent data structures, which are updated incrementally.

> * The return code is still a 200, I would have expected an error return
> code.

If a map function causes an error, then no rows corresponding to that
document are added to the view btree, but the view btree still exists and
can be successfully queried.

It's best to think of map-reduce functions like this:

1. User adds/updates a document
2. Document is passed to map function
3. Map function emits key/value pairs for the view btree
4. User queries the view btree.

Now in practice, view generation is "lazy". It's not until step 4 occurs
that steps 1-3 are triggered, and then step 4 completes. But that's just an
optimisation. Furthermore, if a subsequent query is made to the same view
(without any new documents or updates being made), then only step 4 occurs -
that is, *no* documents are processed by the map function, because if no
documents have changed, then the view itself must be unchanged.

I'm not sure if what I've written will make much sense to a newcomer, but
have a look at the View API documentation on the Wiki to see if that's



View raw message