Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of ryszard.szopa@gmail.com
 designates 209.85.128.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type
         :content-transfer-encoding:content-disposition;
        b=DG7BnGyRizciaC33ZAUpP2Xg6bwAE6DReXbxSMPYTjoK07m7OwyFOwwbNInTv3FoI5
         8guOGOLfGI3uWIZSxkJmfWSzUJSYFryVNlku7nRq/EnF1SyLN8pp+F54f+WYoVXB/uMC
         mwVWzPKrgpzV7tYpA7rJ4gakdgomdtMYJql7Y=
Message-ID: <19e19e410806101432k588a19d7y3db62e20e80c83c9@mail.gmail.com>
Date: Tue, 10 Jun 2008 23:32:57 +0200
From: "Ryszard Szopa" <ryszard.szopa@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: rereduce
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

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
result

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?

Cheers,

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

-- 
http://szopa.tasak.gda.pl/