Hopefully I'm not stating the obvious, but depending on the database being used, I would normally handle this using the database to cascade these deletes.
I know some of the databases torque supports don't support cascading constraints, but many of them do. As a DBA, I prefer to keep rules such as these in the database anyways, because it prevents RI problems. If your using Oracle, Sybase or MS SQL Server, I could probably get you a syntax snippet to cascade the deletes. Good Luck, -----Original Message----- From: Marty Phee [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 10:58 PM To: Turbine Users List Subject: Re: Issues w/ Torque joins & deletes I tried to do the same thing, and ended up hard-coding the doDelete with the parent, and then the child. Doesn't the Criteria object have a Cascade option? I looked through the doDelete code, and there is code that looks for children, but it didn't seem to work. I never went and stepped through it though. Personally I like this option: > Criteria crit = new Criteria(); > crit.add(PositionPeer.SECTION_ID, getSectionId()); > crit.addJoin(SectionPeer.SECTION_ID, PositionPeer.SECTION_ID); > crit.addJoin(PositionPeer.POSITION_ID, OptionPeer.POSITION_ID); > OptionPeer.doDelete(crit); I like having control over what happens. On Thu, 2002-03-07 at 19:47, John McNally wrote: > The doDelete method does nothing more than delete a single row, if it > can find the primary key in the Criteria passed in. It is not a very > elaborate method. Unless you want to work on it to make it better, I > can only suggest to hardcode your sql and use BasePeer.executeStatement > > john mcnally > > Charles Duffy wrote: > > > > Howdy. I have three tables: section, option and position. The > > relationship between each is 1:n (so there can be n options per 1 > > section and n positions per 1 option). There are no foreign keys which > > reference the option table. > > > > I'm trying to write code to delete a section and all the options and > > positions associated with it. In trying to select all the associated > > options, I do the following: > > > > Criteria crit = new Criteria(); > > crit.add(PositionPeer.SECTION_ID, getSectionId()); > > crit.addJoin(SectionPeer.SECTION_ID, PositionPeer.SECTION_ID); > > crit.addJoin(PositionPeer.POSITION_ID, OptionPeer.POSITION_ID); > > OptionPeer.doDelete(crit); > > > > When this segment gets run, however, the following occurs: > > > > 3361 [main] DEBUG org.apache.torque.util.BasePeer - BasePeer.doDelete: whereClause=SECTION_ID=2 > > org.apache.torque.TorqueException: ERROR: <unnamed> referential integrity violation - key in position still referenced from option > > > > It appears that a deletion from position (rather than option) is being > > attempted. I've surrounded the code in question with logging statements, > > so I'm quite certain of its position. > > > > Calling OptionPeer.doSelect(crit) for this same criteria results in the > > correct data being returned. Indeed, the following (less efficient) code > > snippet works: > > > > crit = new Criteria(); > > crit.add(PositionPeer.SECTION_ID, getSectionId()); > > crit.addJoin(SectionPeer.SECTION_ID, PositionPeer.SECTION_ID); > > crit.addJoin(PositionPeer.POSITION_ID, OptionPeer.POSITION_ID); > > Vector v = OptionPeer.doSelect(crit); > > for(int i=0; i<v.size(); i++) { > > ((Option)(v.elementAt(i))).remove(); > > } > > > > where Option.remove() is simply a call to OptionPeer.doDelete(this) > > > > Anyone know what's going on here? > > > > Thanks! > > > > ------------------------------------------------------------------------ > > Part 1.2Type: application/pgp-signature > > -- > 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]>
