cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <>
Subject Re: Change audit framework
Date Thu, 27 Aug 2015 12:26:22 GMT
I'd like to have structured data that can be inspected for particular keys,
usually attribute names. Rather than a serialized form. My use involves
setting a modification time but only if some interesting parts were changed.

For what it's worth, what Wonder has is two dictionaries, one with the
committed values and one with the current values, and the changes can be
derived from that.
On Thu, Aug 27, 2015 at 6:11 AM Andrus Adamchik <>

> It appears that in mine and everybody else's work capturing object changes
> is a must-have. We have these discussions on user@ periodically, and 70%
> of my clients have one or another implementation in their apps. So maybe we
> can do something about it in Cayenne. The first attempt at it is already
> available since 3.1 [1]. Still AuditableFilter is more like an example to
> follow, than a drop-in implementation. So everyone keeps coming back with
> that same question about audit.
> The challenge here is spare the user from the change analysis, but allow
> to customize a few extra things:
> 1. the mechanism where this data is stored (can be saved in the DB,
> broadcast via MQ, stored in Kafka, etc.)
> 2. additional contents of the audit trail (security context, transaction
> id, client IP address, etc.)
> 3. filtering entities we want to audit from other data changes.
> I think I'll be able to open-source a new version of the AuditableFilter
> that is pretty close to this. It emits a stream of changes as JSON:
> {"ts":1427090346831,"by":"someuser","serverIP":"","op":"UPDATE","id":"MyEntity:954619","changes":{"email":["
> The stream is a complete change log that doesn't lose anything. This
> includes all possible object graph operations (create, update, delete,
> relationship changes, ID changes). The object model behind this framework
> is quite reusable. Filtering can be done either with entity annotations, or
> straight on the change object stream. STDOUT can be the default storage
> (and JSON - the default format for that), and we let the users to override
> it.
> Does it sound like something you can use to rewrite your current audit
> framework?
> Comments?
> Andrus
> [1]

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