Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 64.74.157.62 as permitted sender)
Date: Tue, 14 Jul 2009 13:32:38 +0100
From: Brian Candler <B.Candler@pobox.com>
To: user@couchdb.apache.org
Subject: Using _list for query post-processing?
Message-ID: <20090714123238.GA10979@uk.tiscali.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

The _list documentation on the wiki at
http://wiki.apache.org/couchdb/Formatting_with_Show_and_List seems to be out
of date, because AFAICS the API has changed to a "pull" using getRow().

I am wondering whether the list API is suitable for filtering a JSON result
set before returning it to the client. Examples would be:

(1) Showing only keys which appear more than N times (dupes)

(2) Negative views: showing documents which are missing a particular
tag or attribute (*1)

(3) Experimenting with custom grouping logic - albeit an inefficient
implementation as it couldn't skip over Btree nodes with same group keys (*2)

The basicJSON example in share/www/script/test/list_views.js suggests that
it should work. It can iterate over the whole view result set and send out
whatever values it chooses. It also suggests that req.query would give me
the parameters to the query. So I'll give it a go and see what happens.

However, is there something analogous to _temp_view for trying out list
functions? Or do these always have to live in design docs?

At the moment, maybe the overhead of sending X thousands documents to the
list server for filtering isn't much different to the overhead of sending X
thousand documents over HTTP to the client for local filtering; but once we
have erlang views, that could change drastically.

Thanks,

Brian.

(*1) You can make a view which emits null if a specific attribute is
missing. However this logic is hard-coded into the view. I'd like to be able
to select documents meeting one key-range criteria, and then filter them to
see which are missing another dynamically-chosen attribute.

(*2) There might be value in allowing the list server to tell couchdb to
skip straight to key K2, but this wouldn't be very useful without having the
reduced value between K1 and K2.