Child pages
  • Development-Audit Trails

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 were 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:

Code Block

auditTrailChanged()
auditTrailInsert()
auditTrailDelete()

...

In psuedo code:

Code Block

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

...