Hey Chris, On May 22, 2008, at 06:07, Chris Anderson wrote:
These are good changes, and it's important to have the same API for views and temp views. Question: are there plans to allow access to the results of the map stage of a map/reduce pair? It would certainly be helpful for debugging, and I can imagine circumstances where one might want to use both of them in an application, while avoiding the overhead of duplicate map functions.
That was my first question, too! :) You need to create a second design document that has only a map function to get that. But if you create that map function as a byte-for-byte exact copy of a map function that already exists in a map/reduce view, CouchDB will re-use the existing index. So you can't avoid the duplicate map function, but you can avoid the duplicate view index. Cheers Jan --
Further over the horizon I imagine sharing maps among reduce functions - maybe the reduce key could optionally support an array of reduce functions, rather than just the string. Looking forward to specifying start and end keys for the reductions, so we can really see what they can do! Chris On Wed, May 21, 2008 at 11:08 AM, Jan Lehnardt <[EMAIL PROTECTED]> wrote:Dear CouchDB aficionados, we made a couple of changes in trunk that are not backward compatible with earlier versions of CouchDB. Theses are necessary changes and we do them now in preparation for an 0.8 release. If you have software that uses CouchDB, it is likely to require changing. Sorry about that :-) The changes in detail: Views now support optional reduce. For this to work, the structure of view documents had to change. An example is probably the best way to illustrate them: { "_id":"_design/foo", "language":"javascript", "views": { "bar": { "map":"function... ", "reduce":"function..." } } } Notable changes are the usage of a JSON object to define both the map and the reduce function instead of just a string for the map function. Again, the reduce member may be omitted. The "language" member is no longer a "proper" MIME-Type, instead, only the actual language's name is stated. Confusingly, we used a "map()" function to be used within the actual map function (or view function) to place a key and value in a view's result list. This function is now called "emit()" to avoid confusion. function(doc) { emit(doc.foo, null); } Temporary views now need to get POSTed a proper JSON document with map and reduce members instead of just posting in the map function's source: { "map":"function...", "reduce":"function..." } Note that the language of the view functions is no longer determined by the Content-Type header of the HTTP request. Since the definition is a JSON object, the Content-Type is always application/json. { "language":"javascript" "map":"function...", "reduce":"function..." } You specify the language of the temp view in an optional "language" member. If omitted, it's value defaults to "javascript".-- Chris Anderson http://jchris.mfdz.com
