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 jchris@gmail.com designates
 209.85.146.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:mime-version:content-type
         :content-transfer-encoding:content-disposition:x-google-sender-auth;
        b=HNBNeysATwGKdIvzyo4+JRnI09/OXAmxfn21qTwEN6KEqPILdixh6xkXvyk91z8RLs
         HK+7Ye67VWOY96+sG0xYrwYqKWH7PPZUbCU/ymKpZnozZHcIBGgEgR0tgqOv4ZjBah9V
         1jMi0az98frIIXGoaqtf7mwkw9jbmrWltNrK4=
Message-ID: <e282921e0807111251o1e85f607yd14ce9d346bfcc2b@mail.gmail.com>
Date: Fri, 11 Jul 2008 12:51:07 -0700
From: "Chris Anderson" <jchris@grabb.it>
Sender: jchris@gmail.com
To: couchdb-user@incubator.apache.org
Subject: reduce function without return value
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm implementing a job-pool with CouchDB, and have found a use-case
that the reduce functionality almost-but-not-quite handles perfectly.

I'd like the option to have reduce functions elect not to return
anything (or undefined I guess as they'd look the same to the
interpreter) and have that key be left out of the final group=true
result altogether. Currently the reduction process fails with the
"Cannot encode 'undefined' value as JSON" error.

The idea is that I have a view that calls emit(key,"todo"). A job
runner picks up the keys and runs a job. When the job is complete, the
job runner creates a document which then emits to the same key, but
with value "done". Completed jobs show up in the map as (key, "todo")
next to (key, "done"). Currently I can write a reduce fro group=true
which is always (key, "done") once the job is complete. I'd like to
have a reduce where the "done" keys are completely absent.

Not high-priority (I can just ignore the done keys for now) but it
will be a nice thing to have once I get into a situation where the
majority of keys are done.

I haven't thought through the consequences when group=false, but the
job pool pattern seems a common enough use case to consider.

Is it possible to support this behavior?

-- 
Chris Anderson
http://jchris.mfdz.com