> On Sep 23, 2015, at 12:58 AM, Aristedes Maniatis <[email protected]> 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;
// DELETE, INSERT, UPDATE
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.
Andrus
[1] https://jersey.java.net/documentation/latest/message-body-workers.html
