couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Mielicki <mieli...@gmail.com>
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.group, 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).

Regards,
Łukasz


2011/2/23 Paul Davis <paul.joseph.davis@gmail.com>:
> 2011/2/23 Łukasz Mielicki <mielicki@gmail.com>:
>> 2011/2/23 Paul Davis <paul.joseph.davis@gmail.com>:
>>> 2011/2/23 Łukasz Mielicki <mielicki@gmail.com>:
>>>> 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.
>

Mime
View raw message