I believe the situation is that those functions are not given any
information that could change the results of map() and reduce().
{ "_id": "_design/example"
, "multiply": 50
, "views":
{ "a_view":
{ "map":
"function(D) { emit(D._id, D.value * this.multiply"
}
}
}
Changing .multiply would not invalidate the view signature but it should.
On Tue, Feb 28, 2012 at 9:42 AM, Randall Leeds <[email protected]> wrote:
> Which part of the document are you missing? I know attachments are not sent
> because that's a lot of overhead for people who attach static resources to
> the design doc. Anything else?
> On Feb 27, 2012 4:12 PM, "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)
>>
>> Regards,
>> Ronny
>>
--
Iris Couch
