WebObjects/Web Applications/Development/Audit Trails

Pierce T. Wetter III

This gets discussed a lot, so there's plenty of examples around. For instance, here's an implementation by someone else I found via Google: http://web.archive.org/20050215013412/homepage.mac.com/i_love_my/code.html

However, unless you're insane enough to need to log every change to every object, the concept of an "audit trail" ends up being application specific in many cases. If you can simplify the requirements at all, do so. For instance, at www.marketocracy.com, we never "delete" a fund, we just mark it deleted. Similarly in forums, we don't "delete" forum posts we don't want to show, we "hide" them.

Funds we can't delete because they are cross linked to too many objects, but forum posts I purposely setup to not be deleted because I knew the day would come when someone went "oops" (and they did). So those tables have a flag, and the relationship is defined such that it ignores the "deleted" objects.

For "forecasting and recall" on www.marketocracy.com we record every trade already, so it was fairly easy in the business logic to add methods so that you could "time travel" to any point in time. That is, a trade adds shares to your account while subtracting from your cash (or the reverse). So shares on any position at any point in time is sum(trade.shares where date < desired time). So we've been able to avoid the need for an audit trail, because we already have an "accounting model" in that every operation is recorded as a transaction. In fact if I had to do Marketocracy over again, I might implement it as a double-entry bookkeeping system instead.

If I was going to log every change to every object, some typical hints are that if you subclass EOEditingContext, then prior to any saveChanges() operation you can get a list of the inserted/deleted/changed objects (you have to call processRecentChanges() first). If I was designing this, I'd make all my EOF objects have a common superclass/interface that implemented something like:

 auditTrailChanged()
 auditTrailInsert()
 auditTrailDelete()

Then on a class-by-class basis I could decide what to do. That could include inserting additional objects, etc. Like an object could compare itself to its snapshot if it had changed and it could record the old and new values to a generic object that stored AuditTrail(class name, primary key of object, username, timestamp, attribute, old value (string), new value(string)).

In psuedo code:

 override saveChanges()
   self.processRecentChanges()
   foreach obj (self.changedObjects)
     obj.auditTrailChanged()
   foreach obj (self.insertedObjects)
     obj.auditTrailChanged()
   foreach obj (self.deletedObjects)
     obj.auditTrailChanged()
   super.saveChanges()