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. -- Chris Anderson http://jchris.mfdz.com
