couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: reduce order vs descending
Date Wed, 23 Feb 2011 19:30:45 GMT
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