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?
