On Fri, Mar 14, 2014 at 9:18 AM, Suraj Kumar <[email protected]> wrote: > In our app, we have the notion of named classifier functions which > categorize documents into N (system defined) categories. The categories by > themselves are nothing but names associated to functions which will return > true/false for each document. We would so love to see this app take off the > ground by merely using the changes API filter functions as classifier > functions and have an external (node.js) program subscribe to these streams > and sets the name into the document per our definition. Ideally, once > 'categorized', unless things change, the document may not even require a > re-categorization. > > I'd like to expose the list of possible categories to the outside world: In > other words, I'd love to simply emit() the top level keys of a filter > function defining part of design documents. > > But, from what I understand, views don't see design docs. What is the > recommended way of building indexed metadata about design documents? Or, > how do I go about implementing a classifier system the _right_ way? > > For the lack of such a system, I think, it makes sense to modify couchDB > core to make it support, like Validate Doc Update functions, a set of > Classifier functions. It would have to behave exactly like VDU, except the > JS function can also return the changed document and couch writes the > changed part also. We are thinking of doing this to avoid an external > changes stream processor, but if there is a standard way in which this can > be done, we'd like to listen and do it that way. > > Your thoughts? > > Thanks, > > -Suraj > > -- > An Onion is the Onion skin and the Onion under the skin until the Onion > Skin without any Onion underneath. >
Set the option `include_design` [1] to true in your design doc and you will be able to see the design docs in your views. [1] https://github.com/apache/couchdb/blob/master/src/couch_index/src/couch_index_updater.erl
