As it stands, you can modify the doInsert, doDelete, doUpdate and doSelect methods in your OM peers to first check a cache / run business logic before and/or after that specific operation.
So, for your case below, instead of adding a AuditBook to your hierarchy you could have just overridden the AuthorPeer.doSelect(Criteria, DBConnection) to first perform audit logic, then the select. Even though the getAuthor() method uses AuthorPeer.retreiveByPK(), Torque Peer retrievals eventually use doSelect(Criteria, DBConnection) to hit the db, so overriding this single method in your Peer allows you to easily add supplemental functionality transparently to object retreival. Scott -----Original Message----- From: Pugh, Eric [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 9:48 AM To: 'Turbine Users List' Subject: RE: [Torque] Caching [WAS Re: [Torque] Failed testcase] Just to chime in, my experience with trying to add an audit layer to my OM objects highlighted the same problem with calls like book.getAuthor(). When I demoed Turbine to my local JUG, they absolutly loved the power of book.getAuthor().getLastName(), and I wouldn't want to lose that ease of use! But it makes it much harder to insert some sort of logic that does something with the call to getAuthor(). I ended up adding Book extends AuditBook extends BaseBook extends BaseObject. And in AuditBook is the method getAuthor() that does a super.getAuthor() and then does my auditing logic on the returned Author object. It seems to me that being able to relatively insert multiple layers in Torque might be useful. Set up , so that each layer doesn't directly depend on the next. So if I wanted the caching layer as well, I might have a class structure like this: Book extends AuditBook extends CacheBook (or CacheObject) extends BaseBook extends BaseObject. I can not wait to see the caching code, I think it will help my applications performance immensely! Eric -----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 9:32 AM To: Turbine Users List Subject: Re: [Torque] Caching [WAS Re: [Torque] Failed testcase] On 12/18/01 6:50 AM, "Kelvin Tan" <[EMAIL PROTECTED]> wrote: >>> Is Aaron's package Torque-specific or a generic cache package? >> >> General tool. > > Hmmm... > > Do you anticipate any problems with implementing it in Torque then, based on > the concern raised below? I don't know yet. Torque isn't released and there may certainly be some problems but we'll come to that bridge when we get there. > >>> However, due to the way Torque's business objects are created, after the >>> business objects have been returned to the calling code, a cache is >>> effectively useless since invoking something like book.getAuthor() > basically >>> makes a direct database request, bypassing the cache (_unless_ the cache >>> sits between the objects and its peers, which would make it pretty >>> Torque-specific and involve extensive modifications to Torque code, I >>> think). >>> > > Kelvin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
