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. --
