Hi, On Thu, Nov 19, 2009 at 12:46 AM, Adam Kocoloski <[email protected]> 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
