couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Audit log (was Streaming API in CouchDB 4.0)
Date Fri, 24 Apr 2020 21:29:18 GMT
Hi Gordon,

I wanted to pull this out of the streaming API thread as I think it is a pretty separate (but
important) topic.

I have definitely found occasions where I wanted better auditability for document updates.
I’d be curious to hear more about what types of delivery guarantees you’d want to see
from an audit plugin, and what type of output / destination it should support. Cheers,

Adam

> On Apr 9, 2020, at 2:23 PM, Gordon Baird <gordon@bairdpartnersltd.com> wrote:
> 
> I would like to chime in on this (apologies if it is out of sequence or if not right
context, but would like to raise the concept).   One of the issues we face for our enterprise
deployments in considering CouchDB is our ability to log or serialize the edits and changes
to the documents (a kind of version control or version back reference ability  - we are considering
Couch for regulatory compliant installs with strict audit controls and reporting requirements)
 -  -   We had been talking internally that it would be a material improvement for CouchDB
if it had something like the following…
> 
> 
> Allow a database to be configured with an option to… have an external system subscribe
to changes to a “document record” that then would allow for the full pre-change document
to be sent to a separate application / logging system …  at the current point go the “revision”
,  allow for a “copy” of the original, before change occurred to be made, flagged and
if subscribed to, have that full document sent out to a third party system… something similar
to how RabbitMQ works with a separate login system “hooked” into the message broker but
not integrated so that does not slow down performance or disrupt the native Erlang flow. 
    Understand that this extra step of “copy and send” original prior to “revision update
and store” involved an additional “copy” and might impact performance some, maybe this
is a configurable option for each database that can be toggled if the audit feature is more
valuable than the give up on some performance.       Something like this would be very valuable
because it would allow a separate application to keep track of the versions of older “json
 documents” - that were native CouchDB, but without burdening CouchDB to try and be a full
versioning, serializable database..    [maybe just send the raw native Erlang message / map
 as the message ..]
> 
> Again, apologies if out of context or not right place to chime in on this.   We are still
somewhat new to and still learning all the features and nuances in consideration for our enterprise
applications.    If helpful, can expand on further - both use cases and design / BIF libraries
ideas … 
> 
> Gordon

Mime
View raw message