couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Changes in trunk
Date Thu, 22 May 2008 07:09:57 GMT
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 <jan@apache.org> 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
>


Mime
View raw message