Thanks for answering; I already tried Criteria deletion, although my object and corresponding database table have PK. It didn't work.
JDBC and Torque DB paths are the same. Torque version is old, but I am programmer not DB administrator so I can't make migration myself. Sure, after this issue I'll ask for newer Torque. The thing that's happening here is obviously some delayed deletion. It reminds me of write-back method used in hardware cache memories (some other methods use write-through). After writing, data is only invalidated and first time processor asks for that data real write is done and updated data is provided back to processor. Like so, when I ask for deleted object via Torque real deletion happens and data is not reachable neither by Torque nor JDBC. It is only strange to me that there is not some "flush" or write-through command to keep Torque and JDBC in sync. If you say that Torque doesn't have delay than it could something with Postgres. Anyway if you have some more ideas I'll be happy to hear (read) them, while waiting for newer Torque to be installed. Regards, Ivanko -----Original Message----- From: Greg Monroe [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 8:39 PM To: Apache Torque Users List Subject: RE: Cache problem after delete First, I'd suggest upgrading to the latest version of Torque (3.2 / 3.3 coming soon!) from 3.0. There have been a lot of things fixed, etc. Next, Torque does not have a delayed delete mechanism. When you make the delete call, it does a JDBC delete call to the DB right then. Note that currently loaded OM objects are not effect/updated by this. (Other than the one used to make the delete gets it's isNew() status updated). FWIW, it's much safer to delete stuff by using criteria than objects. If the object does not have a primary key to identify it, then the delete statement becomes a based on a concatenation of all the properties. Things like default values can cause the object not to be found and deleted. Hmm, any one remember if 3.0 cared about PKs... I seem to remember it was added later. Anyway, if your table has primary Keys, try using: ClassNamePeer.doDelete(deleteObject.getPrimaryKey()); If not, construct an identifying criteria and use this. Hmm, another thought, based on your Torque can't find it and JDBC can, is that your Torque.properties setting might be pointing to a different location than JDBC. E.g., development DB for Torque vs JDBC using production DB? Good luck. > -----Original Message----- > From: Ivan Ivankovic [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 16, 2006 12:42 PM > To: [email protected] > Subject: Cache problem after delete > > Hi, > > > > I worked with Torque only for past 2 weeks, and I found it > very useful. > > > > I use Torque 3.0 with Postgres and have following problem: > > After deleting some concrete object with usual > ClassNamePeer.doDelete(objectToDelete), I can still see it in > database when querying for that objects information with plain JDBC. > > > > When I use any of Torque query methods, via Criteria or > retrieveByPK(key), object seems to be erased, but some parts > of application I am working on use JDBC so I can't rewrite > all code to use Torque BasePeer.executeQuery(queryString). > Database data for this object can also be seen from Squirrel > JDBC browser which of course uses plain JDBC. > > > > I suppose that Torque has some delayed deletion mechanism and > I need some way to make him do the actual deletion completely > from database. Is there some kind of "flush" to achieve this? > > > > Regards, > > Ivanko > > Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.6/535 - Release Date: 11/15/2006 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
