I think ideally this fits as low on the persistence mechanism as possible
(i.e., the DB). However, the thought of implementing this as a web of
triggers, when I have a nice Object layer directly above, just seems silly.
I impetus behind this is that I am writing a thin interface layer over (and
hiding) the particular O/R implementation; much like you have spoken about
on this list quite a few times. Currently Castor is built and OJB is a work
in progress and TopLink is on the horizon. Castor has no such concept,
although they too have the callback mechanism. This is what lead me to the
InvocationHandler/Map/Journaler approach. Basically the domain objects
extend a base, which instantiates a InvocationHandler-wrapped Map and
listens for persistence callbacks. The Map also has an attached
"Journaller" responsible for maintaining changes state of the object
(similiar to the DB concept). At transaction start, it initiailizes the
Journaler and begins recording changes. At commit, it notifies an EventHub
which is responsible for in turn notifying the integration and audting
gateways.
Then, on doing some advanced scouting on the TopLink stuff, I noticed the
changeset stuff and thought it would be really, really nice to have this
refactored out of the domain classes theselves. I guess, I wasn't thinking
of the processing integrated into the O/R layer, just a callback-level
interface so that parallel systems could basically register interest in
changes.
With the OJB persistence wrapping, I was hoping to utilize the PB approach.
But it sounds like this will not be possible.
|-----Original Message-----
|From: Thomas Mahler [mailto:[EMAIL PROTECTED]
|Sent: Tuesday, February 25, 2003 2:16 PM
|To: OJB Users List
|Subject: Re: auditing mapped classes
|
|
|Hi STeven,
|
|Ebersole, Steven wrote:
|> I'll take silence as a no...
|
|In my case silence just means "tom did not find the time to answer
|yet... or even worse he did miss the original posting..."
|
|>
|> |-----Original Message-----
|> |From: Ebersole, Steven [mailto:[EMAIL PROTECTED]
|> |Sent: Monday, February 24, 2003 10:35 AM
|> |To: OJB Users List (E-mail)
|> |Subject: auditing mapped classes
|> |
|> |
|> |I was wondering if OJB has built-in support for auditing
|> |state changes in
|> |the classes which are mapped under its control. What I am
|> |thinking of is
|> |something along the lines of TopLink's changeset concept.
|
|depends on the API we are talking about:
|- For OJB-PersistenceBroker it's a clear no.
|- For OJB-JDO it's a clear yes. The JDO spec does require JDO
|implementations to do this. The required code is injected into the
|persistent classes by bytecode enhancement.
|- For OJB-ODMG it's a clear "partially":
|in our ODMG implementation all instances managed by a
|transaction are
|inserted into so called ObjectEnvelope objects. The ObjectEnvelope
|implements the contract between a persistent instance and
|the ODMG ty
|management. It contains a snapshot of the persistent
|instance of the
|point in time when it was registered.
|This Envelope is use on TX commit to detect all changes to the
|persistent instance.
|But as we do no bytecode enhancement in ODMG, we don't get
|triggered,
|when user code modifies an instance under ODMG control.
|
|
|> |Currently I have a base domain class which is responsible
|> |for tracking these
|> |property changes, and then publishing notification to an
|> |event manager which
|> |brokers those notifications to auditing and
|integration gateways.
|> |
|> |In TopLink, I could utilize its EventManager and
|DescriptorEvent to
|> |externalize this whole process (basically refactoring it
|> |out of the domain
|> |classes). And basically, I was just wondering if
|> |something similiar already
|> |exists in OJB.
|
|No there is nothing that maps directly to this concepts.
|We only provide
|simple instance callback mechanisms to inform instances about
|persistence operations going on.
|
|But (apart from the bytecode enhanced JDO) we do not
|interfere with user
|code accessing attributes.
|
|
|Do you think this is an important functionality for an O/R layer?
|Where (which OJB layer) could you imagine to fit it in?
|Would a generalized bytecode-enhancement or an aspect
|weaving mechanism
|be a possible solution?
|
|cheers,
|Thomas
|
|
|
|> |
|> |
|> |
|> |
|> |Steve Ebersole
|> |IT Integration Engineer
|> |Vignette Corporation
|> |Office: 512.741.4195
|> |Mobile: 512.297.5438
|> |
|> |Visit http://www.vignette.com
|> |
|> |-----------------------------------------------------------
|> |----------
|> |To unsubscribe, e-mail: [EMAIL PROTECTED]
|> |For additional commands, e-mail: [EMAIL PROTECTED]
|> |
|>
|>
|-----------------------------------------------------------
|----------
|> To unsubscribe, e-mail: [EMAIL PROTECTED]
|> For additional commands, e-mail: [EMAIL PROTECTED]
|>
|>
|
|
|
|-----------------------------------------------------------
|----------
|To unsubscribe, e-mail: [EMAIL PROTECTED]
|For additional commands, e-mail: [EMAIL PROTECTED]
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
