couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leontius Adhika Pradhana <>
Subject Re: Storing immutable docs & accessing all docs as a reduction
Date Thu, 07 Jan 2016 13:03:47 GMT
Although I haven't finished implemented it yet, what I'm thinking about is
to have the app listen to the _changes feed of the "n-fact" docs. Then for
each "n-fact" doc that is being created, the app performs the reduce logic
accordingly to the appropriate docs in another couchdb database. Using the
seq id this should be doable atomically.

As the "n-fact" docs are insert-only (not to be modified), this will make
sure that the "n-fact" docs are processed according to the *time it is
inserted* in the database (this should be true also even if the "n-fact"
comes due to replication if that matters).


Leontius Adhika Pradhana (Leon)

On Thu, Jan 7, 2016 at 4:45 AM, Ronan Jouchet <> wrote:

> 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
>> 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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message