couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
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 10:05:37 GMT
Hi Ronny,

Invalidating views by ddoc _rev change is very bad idea - your 2M docs
database will have to be reindexed on each ddoc update: by adding
attachment or changing show function. Wait, what's the reason for
views to be invalidated in this case?


On Tue, Feb 28, 2012 at 12:45 PM, Ronny Pfannschmidt
<> wrote:
> On 02/28/2012 04:09 AM, Jason Smith wrote:
>> On Tue, Feb 28, 2012 at 7:12 AM, Ronny Pfannschmidt
>> <>  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

View raw message