Re: Changes in trunk

[Chris Anderson <jc...@grabb.it>]

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

Re: Changes in trunk

[Jan Lehnardt <ja...@apache.org>]

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