couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Mielicki <>
Subject Re: reduce order vs descending
Date Wed, 23 Feb 2011 19:59:46 GMT
Thanks, my view is something like this:

map: function(doc) {
  emit(, doc);
reduce: function(keys, values) {
  values.sort(function(x, y) { return (x._id < y._id) ? -1 : 1;});
  var result = {};
  for (var i = 0; i < values.length; ++i) {
    var doc = values[i];
    for (var k in doc) result[k] = doc[k];
  return result;

Documents are incremental updates and _id is guaranteed to increase with time.
For all documents with same key (let's say group) documents are
combined in the way fields of document with higher _id override fields
of documents with previous _id.
I query only in a range of single key/group. I plan to throw or
generate empty result if reduce is applied to docs with adjacent key
to save on view size.

Is a sort stop and preserving _id necessary here?
(descending=true&group=true on query).


2011/2/23 Paul Davis <>:
> 2011/2/23 Łukasz Mielicki <>:
>> 2011/2/23 Paul Davis <>:
>>> 2011/2/23 Łukasz Mielicki <>:
>>>> Hi everybody,
>>>> I can observe that order of values provided to reduce function depends
>>>> on descending query parameter.
>>>> Is this a bug?  Or does Couch support left and right reduce separetely?
>>> Never write code that depends on the ordering of keys in reductions.
>>> It will break. The order is undefined and I don't ever see it being
>>> defined due to lots and lots of edge cases in that code.
>> I pretty confident about my use-case properties. It is similar to
>> finding max value(s), but in my case key/id matters because they
>> contain information (I'm not using UUIDs). The remaining questions is
>> if do I have to sort them in reduce step given descending is always
>> true.
>> IMHO its vital to be able to get both left-reduce and right-reduce
>> semantics over key range.
>> Thanks,
>> Łukasz
> I'm saying that you can't rely on the ordering of keys passed to your
> reduce functions. Which is not the same as relying on the order which
> rich reductions are combined.
> If you post some example data and a description of what you'd like to
> accomplish I might be able to help more concretely on your specific
> case.

View raw message