Re: helper functions in reduce

[Jan Lehnardt <ja...@apache.org>]

On 11 Mar 2009, at 02:29, Chris Anderson wrote:

> On Tue, Mar 10, 2009 at 6:18 PM, kowsik <ko...@gmail.com> 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
--

Re: helper functions in reduce

[Chris Anderson <jc...@apache.org>]

On Wed, Mar 11, 2009 at 6:59 AM, Zachary Zolton
<za...@gmail.com> wrote:
> 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.
>

Check out the CouchApp script, which has macros for including helper
code automatically in view functions when saving the design documents.
This is really the best way to do it, as the functions as stored in
the design doc can not depend on definitions elsewhere in the code. If
there are a set of helpers you'd like to see as sort of a standard
library for MapReduce, they'd make great candidates for inclusion in
the CouchApp vendor package.

Scan the README for mention of the !code macro:
http://github.com/jchris/couchapp/blob/master/README.md

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

Re: helper functions in reduce

[Zachary Zolton <za...@gmail.com>]

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...! ;^)

—Zach

On Wed, Mar 11, 2009 at 2:29 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 11 Mar 2009, at 02:29, Chris Anderson wrote:
>
>> On Tue, Mar 10, 2009 at 6:18 PM, kowsik <ko...@gmail.com> 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
> --
>
>
>
>
>