incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joscha Feth" <jos...@feth.com>
Subject Re: Limiting views to special users
Date Tue, 29 Dec 2009 23:36:00 GMT
Thanks Brian, this helped a lot in understanding why lists are
essential - as of now everything I modeled was done using views - but
if I want determinism based on the user request, I will definitely need
a list...your answer made this clear!

To anybody following this: more here:
http://wiki.apache.org/couchdb/Formatting_with_Show_and_List

regards,
Joscha


Brian Candler wrote:

> 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 clearer.
> 
> Regards,
> 
> Brian.



-- 



Mime
View raw message