couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Rantil <jens.ran...@gmail.com>
Subject Left fold reduction / pluggable view reduction
Date Wed, 09 Nov 2016 22:31:27 GMT
Hi,

I've been eyeing[1][2] CouchDB as a viable event store for event
sourcing[3] for a while. In many cases it's a very good fit and being to
replicate view projections would be awesome.

My main concern is that CouchDB view reduce operations aren't linear. That
is, they aren't strictly a left fold[4]. This makes a lot of view
projections of events much harder to implement than they actually need to
be. Each reduce must take into account both events from back in time as
well as "in the future".

I understand the current implementation is an optimisation to avoid
iterating through all values for a specific key every time `_id` less than
`max(_id)` is inserted/modified/deleted, but in the case of writing
immutable, append-only, data this isn't a requirement[5].

Question: Has there been any discussion around supporting either 1)
pluggable view reduce strategies or 2) (simply) left-fold reduce? Would it
be something that would be of interest as a whole to the community?

Cheers,
Jens

[1] http://jensrantil.github.io/bootstrapping-couchdb-as-event-store.html
[2] http://jensrantil.github.io/a-follow-up-on-couchdb-as-event-store.html
[3] http://martinfowler.com/eaaDev/EventSourcing.html
[4] https://en.wikipedia.org/wiki/Fold_%28higher-order_function%29
[5] Also, a side-effect of left-fold reduction would also mean that
intermediate reduce states could be ditched reducing disk space usage.

-- 
Want to communicate with me securely? You can find my PGP key here
<https://pgp.mit.edu/pks/lookup?op=get&search=0xBA632DB691DA03B8>.

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