Re: two databases from one application
Re: two databases from one application
- Subject: Re: two databases from one application
- From: "Pierce T. Wetter III" <email@hidden>
- Date: Thu, 11 May 2006 08:30:51 -0700
On May 11, 2006, at 2:32 AM, David Avendasora wrote:
Pierce,
Can you elaborate on some of the easier ways to do this? I am
facing this requirement for a project I am working on now. The
intent is to add the functionality after the core system is up and
running but I'd feel much more comfortable with at least having a
strategy now.
I need to maintain a history of a subset of the date in my database
for use in forecasting and recall.
I'm not sure what a history of the "subset of the date" means.
Here's a generic answer.
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://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()
Pierce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden