On Jun 13, 2008, at 11:16, Chris Anderson wrote:
On Fri, Jun 13, 2008 at 1:53 AM, Jan Lehnardt <[EMAIL PROTECTED]> wrote:
On Jun 13, 2008, at 01:40, Brad Schick wrote:
It would be interesting to know the load on the DB of doing
something
like that inside the server versus sending and receiving all million
documents to the client.
You'd save all HTTP handling. So things would be faster. We are at a
point with CouchDB where we are working on getting it right and not
getting it fast or adding features for all edge cases. I'm not
saying that
CouchDB will never get a feature that helps you, but it is not yet a
priority.
That might be something doable via the view server / search query /
line-based json API. A job runner that you can submit jobs to wouldn't
be a bad way to obviate http connection issues. Send the job to the
data, they say. And then you could write job functions in any language
you want.
Building it as a plugin would solve the immediate issue, and allow
CouchDB's core to concentrate on getting it right. Plus job runners
just sound useful anyway, especially for things like functions that
clone a group-reduce result to a new database for further manipulation
and querying.
That sounds much more like it :)
Cheers
Jan
--
