Changes for page Development-Audit Trails

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.tedpet
	1	+XWiki.probert

Content

...	...	@@ -8,9 +8,10 @@
8	8
9	9	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.
10	10
11		-If I 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:
	11	+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:
12	12
13	13	{{code}}
	14	+
14	14	auditTrailChanged()
15	15	auditTrailInsert()
16	16	auditTrailDelete()
...	...	@@ -22,6 +22,7 @@
22	22	In psuedo code:
23	23
24	24	{{code}}
	26	+
25	25	override saveChanges()
26	26	self.processRecentChanges()
27	27	foreach obj (self.changedObjects)