couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
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 02:52:48 GMT
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 <randall.leeds@gmail.com> 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" <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)
>>
>> Regards,
>> Ronny
>>



-- 
Iris Couch

Mime
View raw message