couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryszard Szopa" <>
Subject rereduce
Date Tue, 10 Jun 2008 21:32:57 GMT

I've updated CouchDB to revision 666301 just to realize that something
has changed in the view-server protocol. Namely, CouchDB started
sending 'rereduce' which completely confused my soon-to-be-ready lisp
view-server. If I have figured out this right, instead of sending
["reduce", ...] and calling the reduce function on a list of (key
value) pairs, it

1) Sends "reduce" and calls reduce on a fragment of the complete
keys-and-vals list (in the cases I tested, from 4 to 9), stores the

2) Sends "rereduce" and the list of partial results and expects them
to be reduced. In couchjs the reduce function takes a new argument
which determines whether it is in the reduce or rereduce phase.

This incremental mapreduce looks like a great idea (changing one
document doesn't make it necessary to recalculate the whole view), but
the interface doesn't seem really optimal. It forces the user to write
functions that have completely different behaviors and expect
different kinds of things as arguments depending on one argument. This
isn't really clean or elegant. Wouldn't it be a lot easier to make
views have an additional attribute, rereduce?


    -- Richard

PS. The new view-server protocol is not documented on the wiki (it
says nothing about reduce, not to mention rereduce). I could do that,
but as I have only reversed engineered the protocol from the behavior
of CouchDB (so I cannot say I really *know* it) I would like somebody
to confirm I've got it right.


View raw message