couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Li Zhengji <>
Subject Re: some thoughts on view
Date Thu, 19 Nov 2009 01:16:31 GMT

On Thu, Nov 19, 2009 at 12:46 AM, Adam Kocoloski <> wrote:
> Hi,
> We already do this -- if two views in a design document have byte-identical map functions,
the map is only run once, the index is only saved once, and the different reduce functions
share that index.

I realized that it might be hard to cache results of reduce, so
multiple reduce is hard to do.

But for the binary compare of  map functions, I don't think it's a
good idea. Maybe, we can use a special field to say that we are
sharing the same map function of another view.

>> 2. Why "reduce", let's "fold"

>> fun (keys, values, Acc) -> updated Acc.
>> We just need to attach an "Acc" field for reduce in view doc.

When I am riding home, I found that I am wrong on fun(keys, values,
Acc) which can't do "rereduce". At least, it should be something like
fun(keys, values, [Acc..]).

> I agree, reduce is a bit warty.  I'm seeing an awful lot of people write reduce functions
that don't properly account for the possibility of rereduce.  Their views work fine on small
datasets, but they've got this hidden bug that may only manifest itself in production.

I agree. With a better idea, it's harder for people to write bad code.
I believe that there would be a better solution for reduce, just as
the "map" API in the map function is replaced by "emit".

> On the face of it, I'm not sure the "fold" approach is a good match for the btree-based
index storage that CouchDB uses.  But maybe I'm just not thinking about it hard enough.
> Thanks for posting these thoughts -- always nice to get a fresh look at things.  Best,
> Adam

Li Zhengji

View raw message