couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary Zolton <>
Subject Re: helper functions in reduce
Date Wed, 11 Mar 2009 13:59:20 GMT
I was a bit mislead by the title; this sounds like caching the
parsed/ready-to-go JavaScript view functions.

However, I am interested in hearing how we can introduce helper code,
and reusable libraries, into our JavaScript views.

Perhaps one could take care of both in one go? If this doesn't get
implemented soon, I'll take a shot at it. Dang work responsibilities
getting in the way...! ;^)


On Wed, Mar 11, 2009 at 2:29 AM, Jan Lehnardt <> wrote:
> On 11 Mar 2009, at 02:29, Chris Anderson wrote:
>> On Tue, Mar 10, 2009 at 6:18 PM, kowsik <> wrote:
>>> And the source code as defined in the view is parsed and executed
>>> __each__ time reduce is called on the changed docs. I think the intent
>>> was that the view server has no clue when _design views actually
>>> change. So couchdb passes in the actual string corresponding to the
>>> view function each time it wants couchjs to reduce a bunch of
>>> key/values. I suppose you could precompile these functions in the view
>>> server and have it return "handles" to couchdb that can be used at a
>>> later stage.
>> We've discussed a little on IRC, how to optimize this. The plan so
>> far, is to maintain in CouchDB's ets tables of couchjs processes, a
>> list of functions known by each process (where functions are named by
>> their md5 hash). When a function is passed to a query server, it'll be
>> passed along with its name, the first time. If a server already knows
>> about the function, Couch will just pass the name in subsequent
>> requests. If they somehow get out of sync CouchDB can just kill that
>> server and start fresh.
>> This also means that if you have lots of dbs with the same views in
>> them, you get nice reuse of couchjs processes.
>> Anyone feel like implementing? ;)
> *cough* …maybe dev@.
> Cheers
> Jan
> --

View raw message