Hi, Yes, that's what I'm referring to, the javascript reduce function.
I'm curious what you do with custom reduce that isn't covered by the built-in reduces? I also think if custom reduce was disabled by default that we would be motivated to expand this set of built-in reduce functions. B. > On 13 Oct 2020, at 17:06, Jonathan Hall <fli...@flimzy.com> wrote: > > To be clear, by "custom reduce functions" you mean this > (https://docs.couchdb.org/en/stable/ddocs/ddocs.html#reduce-and-rereduce-functions)? > > So by default, only built-in reduce functions could be used > (https://docs.couchdb.org/en/stable/ddocs/ddocs.html#built-in-reduce-functions)? > > If my understanding is correct, I guess I find it a but surprising. I've > always thought of map/reduce of one of the core features of CouchDB, so to > see half of that turned off (even if it can be re-enabled) makes me squint a > bit. And it is a feature I use, so I would not be in favor of deprecating it > entirely, without a clear proposal/documentation for an > alternative/work-around. > > Based on the explanation below, it doesn't sound like there's a technical > reason to deprecate it, but rather a user-experience reason. Is this correct? > > If my understanding is correct, I'm not excited about the proposal, but > before I dive further into my thoughts, I'd like confirmation that I actually > understand the proposal, and am not worried about something else ;) > > Jonathan > > > On 10/13/20 5:48 PM, Robert Samuel Newson wrote: >> Hi All, >> >> As part of CouchDB 4.0, which moves the storage tier of CouchDB into >> FoundationDB, we have struggled to reproduce the full map/reduce >> functionality. Happily this has now happened, and that work is now merged to >> the couchdb main branch. >> >> This functionality includes the use of custom (javascript) reduce functions. >> It is my experience that these are very often problematic, in that much more >> often than not the functions do not significantly reduce the input >> parameters into a smaller result (indeed, sometimes the output is the same >> or larger than the input). >> >> To that end, I'm asking if we should deprecate the feature entirely. >> >> In scope for this thread is the middle ground proposal that Paul Davis has >> written up here; >> >> https://github.com/apache/couchdb/pull/3214 >> >> Where custom reduces are not allowed by default but can be enabled. >> >> The core _ability_ to do custom reduces will always been maintained, this is >> intrinsic to the design of ebtree, the structure we use on top of >> FoundationDB to hold and maintain intermediate reduce values. >> >> My view is that we should merge #3214 and disable custom reduces by default. >> >> B. >>
