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 <[email protected]> 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
