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 <[email protected]>:
> 2011/2/23 Łukasz Mielicki <[email protected]>:
>> 2011/2/23 Paul Davis <[email protected]>:
>>> 2011/2/23 Łukasz Mielicki <[email protected]>:
>>>> 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.
>
