couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronan Jouchet <ronan.jouc...@cadensimaging.com>
Subject Re: Storing immutable docs & accessing all docs as a reduction
Date Wed, 06 Jan 2016 21:45:06 GMT
Hi Leontius, everybody.

On 01/06/2016 12:35 AM, Leontius Adhika Pradhana wrote:
> Re #1. I have been thinking along the same lines lately. My biggest
> gripe with this concept is that couchdb isn't able to perform further
> mapreduce to the results of a reduce (i.e. the "latest state of the
> doc"). Thus, we can't query the resulting docs at all except by key.
> Of course we could copy the result of the reduce to another doc/db to
> write views on, but then conflict issues would come up again like
> normal docs.
> What's your take on this issue?

Fully agreed, nothing to add.

> Re #2. Take a look at
> http://stackoverflow.com/questions/20303355/why-do-couchdb-reduce-functions-have-to-be-commutative
> Basically, reduce functions are expected to be commutative
> (f(a,b) == f(b,a)), so it is perfectly legal for couchdb to shuffle
> the arguments to reduce functions.

Thanks, didn't know about that. To me that means to:

  - Either (re-)sort the `values` array by date before the reduce body.

  - Or maybe abandon altogether Couch-side reduction and instead get the
    unreduced (group_level=2) data, then reduce it client-side.

    * That means more data transferred, which is okay in my case but
      might be overkill/unrealistic for most web apps. Or maybe it's
      negligible with a moderate number of documents and given that
      text compresses well.

    * But having the whole historical facts behind each document might
      be convenient anyway (and occasionally avoid network requests).

  - Something else? Leontius, how did you work around that in your own
    n-facts -> 1-pseudodoc reduce function?

Mime
View raw message