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