couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronny Pfannschmidt <Ronny.Pfannschm...@gmx.de>
Subject Re: feasibility of a design doc option to use the "ddoc new"/"ddoc <id>" based protocol for map and reduce as well
Date Tue, 28 Feb 2012 08:45:43 GMT
On 02/28/2012 04:09 AM, Jason Smith wrote:
> On Tue, Feb 28, 2012 at 7:12 AM, Ronny Pfannschmidt
> <Ronny.Pfannschmidt@gmx.de>  wrote:
>> Hi,
>>
>> while trying to build a a view server for ddocs that validate/support
>> documents as FSM (Finite State Machine)
>> i hit a inherent limit of the protocol,
>>
>> map and reduce don't get the full ddoc, but only a part of it,
>> which means my view server can't actually work with the full ddoc
>> unless i do some weird hacks, and end up in a situation,
>> where i circumvent proper view invalidation
>>
>> if map/reduce where allowed to opt in for using the newer protocol for
>> accessing functions,
>> my problem would go away
>>
>> as for view invalidation, a simple variant could just use the _rev,
>> a more sophisticated one would take a hash of parts of the document
>> (using excludes/includes defined in options as well)
>
> Hi, Ronny. Are you aware that the contents of .views.lib are sent to
> the view server? At least with Javascript, the idea is that CommonJS
> modules can go in there.
>
> Maybe that can help as a workaround for now.
>

Hi Jason,

rather than just a workaround,
i would like to know the likelihood of accepting a patch that implements 
the view option + using _rev as invalidation hint

also i cant find docs on the protocol that's being used for exchanging 
CommonJS of views to the viewserver

-- Ronny

Mime
View raw message