Hi Greg, Thanks for you reply! I've used views before within Torque. But in that case I've problems with inserts/update statements. How do you handle these?
Regards, Robert -----Original Message----- From: Greg Monroe [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 4:15 PM To: Apache Torque Users List Subject: RE: Joins and performance If this is a frequent/heavily used query, another way to deal with this is to create a view and a matching Torque object. There is a table option that suppresses the SQL generation. You can then just use the Peer/Record object as like it was a normal table. Note you may want to pay close attention to the indices requirements of the underlying table. If commonly used columns in a large join are not index, it can be a BIG performance hit. > -----Original Message----- > From: Vitzethum, Daniel [mailto:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 9:40 AM > To: Apache Torque Users List > Subject: AW: Joins and performance > > Hi Robert, > > > If I've 100 companies (which are schools) and 200 buildings, I will > > executes 100 * 200 queries to get all the employees. > > be sure to avoid this... sounds like a killer ;-) > > > In low level SQL > > this query can be combined in one query. Is there a way to handle > > this within Torque? > > In Torque, you can use the Criteria.addJoin() method to link two > tables. > > > Using that feature, you cannot use the Peer.doSelect() method, but > have to use Peer.doSelectVillageRecords(), which will return all > columns of all joined tables in a village Record object, with no big > difference to plain JDBC in handling. If you need or want Torque data > objects, you have to extract them one by one from the result set. > > For a project of us, we wrote a helper class named JoinHelper that > does this business for you AND returns an tree of Torque objects. In > your case, it would return COMPANY objects that can be queried for > their BUILDINGs, which again know their EMPLOYEEs. > > Please search the thread about two years ago in Torque archive and the > discussion about. JoinHelper massively uses reflection, but is tested > quite well and in production. If you have more detailled questions... > you're welcome. > > > Daniel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
