Details
-
Bug
-
Resolution: Fixed
-
Major
-
2.0
-
None
-
Security Level: Public
-
None
Description
The below guideline for writing reduce function from couchdb documentation would be useful to include in the couchbase documentation.
"If you are building a composite return structure in your reduce, or only
transforming the values field, rather than summarizing it, you might be
misusing this feature."
Here's the related thread where user ran into view query errors due to this:
http://www.couchbase.com/forums/thread/newbie-question
and full conversation with Filipe:
Hi Deep,
Yep, reduce functions are supposed to shrink map values (or other
reductions, when doing re-reduce).
Producing arrays for reduction is generally a bad sign, but not
necessarily bad (if they're small and constant size).
Maximum allowed size for a reduction values is ~64Kb (and nearly
unlimited for DP4 and below).
Looking at his function, seems like he's expanding rather than reducing.
On Mon, Oct 29, 2012 at 11:36 AM, Deepkaran Salooja
<deepkaran.salooja@globallogic.com> wrote:
> Hi Filipe,
>
> There is a user issue which I was looking at and need your suggestion on the
> solution I have thought.
>
> The user has written a reduce function which is creating an array of all the
> values for a given key.
> Map-reduce function and sample doc is available here:
> http://www.couchbase.com/forums/thread/newbie-question
>
> I checked the logs and I see he's hitting the "reduction_too_long" error
> while doing view queries.
>
> Looking at the couchdb documentation, I think this is not the correct usage
> for reduce function:
> "If you are building a composite return structure in your reduce, or only
> transforming the values field, rather than summarizing it, you might be
> misusing this feature."
>
> So I am going to suggest the user to move the logic to build the array based
> on similar keys to his application code rather than in the reduce function.
>
> Please let me know if this is the right thing to do here or if there is a
> better alternative.
>
> Thanks,
> Deep