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]>
