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.
