Scott,
I worked on this approach for a while, and actually I have some very crummy
caching code in my doSelect method that checks a global cache to see if the
criteria matches, if it does, it returns the results, versus hitting the DB.
It is not quite done though... (Can't wait for the new caching stuff!).
My problem with this approach is that all the methods are static. And I
need each of my objects to have a user name. So if user A changes a books
title, it needs to record that change, along with user A's name... I
couldn't find anyway for the verious static do methods to access some sort
of service that eventually returns me the result of
data.getUser().getUserName(). So, what I am doing is "tagging" each object
as it comes out of the database with the user's name:
public User getUser() throws Exception
{
User aUser = super.getUser();
aUser.tag(getAuditUserName());
return aUser;
}
Then when it gets saved, in the save() method of the object before we hit
the Peer I am in my AuditBook layer, and can save the audit (including
whoever the user is) data:
public void save(DBConnection dbCon) throws Exception
{
String saveType = "";
if (isModified() ) {
if (isNew()){
saveType = "INSERT";
}
else{
saveType="DELETE";
}
}
super.save(dbCon);
if (saveType != ""){
TableAudit.record(saveType,this);
}
}
Not the best solution since I have to get all my AuditBook methods to match
what torque generates for the BaseBook methods, and it is a whole nother
layer...
Eric
-----Original Message-----
From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 12:09 PM
To: 'Turbine Users List'
Subject: RE: [Torque] Caching [WAS Re: [Torque] Failed testcase]
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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
