Hi all, I have posted a ZIP file of my auditing code. My task was to 1) Simplify how I get objects from my peers (most is very simple select statements), 2) any changes I made to my OM, I wanted to record a username, date, and details in an Admin_audit table, 3) Not have to think overly much about the auditing process, 4) Facilitate reporting back on changes
There are lots of issues and roughspots in the code, but if anyone else wants to use it, please feel free (just drop me a note!). Any improvements would be welcome. Some weak spots are: *when you have more then 1 primary key, the auditing code gets nasty. It expects one primary key, it should expect an array of primary keys. *writing the data to the database involves using a special log4j, requires JDOM, and is very MuseumCompany.com specific. The ZIP file should be available at http://briefcase.yahoo.com/dep4b in the folder Java -> Audit.zip As always, any suggestions would be wonderful.... Merry Christmas, Eric -----Original Message----- From: Pugh, Eric [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 12:34 PM To: 'Turbine Users List' Subject: RE: [Torque] Caching [WAS Re: [Torque] Failed testcase] 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
