cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Change audit framework
Date Wed, 23 Sep 2015 06:42:57 GMT

> On Sep 23, 2015, at 12:58 AM, Aristedes Maniatis <> wrote:
> Why would you perform this serialisation for the user and not just supply a piece of
sample code to put into the listener. Yes, json is the flavour of the day, but some people
will want separate bits of json for every object, others will want to try and assemble the
whole commit tree into one json string, others will want to do something else. Why would Cayenne
itself have an opinion on this format?
> There are very few other places where Cayenne specifies the data format, Hessian being
the only one I can think of.

I used a JAXRS-like approach of a pluggable serializer that produces a desired "media type"
(e.g. [1]). I.e. you simply declare in your method signature that you want a String, and the
framework provides a strategy for converting your object into that String, thus simplifying
the listener code. JSON was supposed to be a default format, and would closely mirror the
object structure. But yeah, serialization does feel out of place like you said. So perhaps
we'll leave it out.

> My other question is about what objects will be found in the change set.

First, here is a structure of the change set object for a single DataObject (this is based
on my internal code, that will be reworked for Cayenne inclusion) :

public class A2ObjectChangeSet {
	private ObjectId preCommitId;
	private ObjectId postCommitId;
	private Map<String, A2PropertyChange> changes;
	private Map<String, Object> snapshot;

	private AuditableOperation op;

	// any extra properties that are common to the entire transaction, 
	// like request IP, or user name
	private Map<String, Object> transactionContext;        

So it has all the info on the object - a snapshot of properties before the object got changed
(e.g. this way you might inspect a a previous state of a deleted object after commit), a list
of changes and any extra metadata associated with transaction.

>  Right now, if you modify an object, listeners can be fired on objects at the other end
of its relations, even if no FK or other changes will be made in the database to those other
objects. Do you anticipate the change set in the audit will include these kinds of related
records, or only ones where a database attribute change is made?

We are tracking changes at the object level, so IIRC the mechanism I am porting to Cayenne
tracks all graph operations, including e.g. to-many relationship additions/subtractions that
do not cause any SQL updates directly.


View raw message