Return-Path: Delivered-To: apmail-db-torque-user-archive@www.apache.org Received: (qmail 98743 invoked from network); 2 Dec 2003 18:01:15 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Dec 2003 18:01:15 -0000 Received: (qmail 11062 invoked by uid 500); 2 Dec 2003 18:00:52 -0000 Delivered-To: apmail-db-torque-user-archive@db.apache.org Received: (qmail 11038 invoked by uid 500); 2 Dec 2003 18:00:52 -0000 Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Apache Torque Users List" Reply-To: "Apache Torque Users List" Delivered-To: mailing list torque-user@db.apache.org Received: (qmail 10929 invoked from network); 2 Dec 2003 18:00:51 -0000 Received: from unknown (HELO mx201.mysite4now.com) (216.250.116.238) by daedalus.apache.org with SMTP; 2 Dec 2003 18:00:51 -0000 Received: (qmail 21834 invoked by uid 104); 2 Dec 2003 17:59:52 -0000 Received: from rs@reazon.com by localhost.localdomain by uid 110 with qmail-scanner-1.14 (spamassassin: 2.43-cvs. Clear:. Processed in 0.291056 secs); 02 Dec 2003 17:59:52 -0000 Received: from adsl-67-112-246-202.dsl.lsan03.pacbell.net (HELO RSC640) (67.112.246.202) by mx201.mysite4now.com with SMTP; 2 Dec 2003 17:59:52 -0000 From: "Ramesh Sabeti" To: "'Apache Torque Users List'" Subject: RE: Torque 3.1 and Prepared Statements .... Date: Tue, 2 Dec 2003 10:00:56 -0800 Message-ID: <000001c3b8fe$3c4a92b0$800101df@rsccd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <90B3A0967470D44CB8FDE749075123289D3553@av1s008.at-work.local> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Siegfried, > 1)) I can definitely patch the Velocity Templates to do the automatic > conversion from Village Records to Torque classes Exactly where do you perform this conversion? I mean which files? > 2)) Same might be true for using doPSSelect() instead of doSelect() but > this is more difficult but can be done. Either generating a direct call to > doPSSelect() or forwarding from doSelect() to doPSSelect() if Oracle is > used. Direct calls to doPSSelect return village records. That would require a lot of programming change. The search/replace I mentioned works great though. > 3) I'm puzzled with SELECT before every update. Since I'm just a casual > TORQUE user I don't know if this an official bug. Can anyone give me/us a > kickstart why there is a SELECT in the first place?! Seems like the SELECT is to ensure a record exists prior to an UPDATE. > 4) Regarding the usage of Prepared Statement I was told that Oracle does > not need to reuse the statement handle it is quite happy with an identical > query string used to create the prepared statement. But as I mentioned > before I'm not a database guru ... :-) Oracle caches a copy of every query string and reuses them. If you don't use prepared statements, Oracle's cache fills up quickly. =20 > Maybe someone can team up with me and with a little bit of help we can fix > the thingies. I'd love to find a solution for these problems, especially #3. How do you want to work on it? Maybe I should post another message about the update issue, hoping to get someone's attention :) Thanks, Ramesh. > -----Urspr=FCngliche Nachricht----- > Von: Ramesh Sabeti [mailto:rs@reazon.com] > Gesendet: Dienstag, 02. Dezember 2003 17:48 > An: 'Apache Torque Users List' > Betreff: RE: Torque 3.1 and Prepared Statements .... >=20 > As you noted, doPSSelect and doSelect don't return the same types. For > Oracle use, you should only use preparedstatements, so doSelect becomes > usesless. At the same time, doPSSelect returns villageRecords and is > not so useful either. I ended up having to change all the calls to > BasePeer.doSelect to BasePeer.doPSSelect in all BasexxxPeer classes > created by Torque (yes, you're not supposed to touch those classes, > unless you really have to :). >=20 > Now I'm having another problem that's literally crashing Oracle. Torque > issues a SELECT before every UPDATE. The SELECT is not a prepared > statement, and fills up Oracle's shared pool in a single day of moderate > use. >=20 > The moral is, if you're using it with Oracle, Torque may not be for you. > Torque needs some minor modifications to make it work with Oracle, but I > haven't seen those made. >=20 > Hope it helps, >=20 > Ramesh. >=20 > > -----Original Message----- > > From: G=F6schl,Siegfried [mailto:Siegfried.Goeschl@drei.com] > > Sent: Tuesday, December 02, 2003 3:19 AM > > To: torque-user@db.apache.org > > Subject: Torque 3.1 and Prepared Statements .... > > > > Hi folks, > > > > I try to convince the company I work for to use Torque instead of the > > textbook "use entity beans with a session facade plus manually written > > data transfer object and fill your first dropdown box in two weeks > time". > > To ensure that Torque is doing well I wrote a regression test suite > which > > works fine. The last addition was testing of Prepared Statements which > > showed a few problems > > > > +) The current implementation returns a List of VillageRecords. Is > there > > any reason why not to generate code which does the following > conversion > > automagically > > > > Foo.addSelectColumns( criteria ); > > ... more criteria wrestling .. > > List recordList =3D FooPeer.doPSSelect( criteria ); > > List result =3D FooPeer.populateObjects( recordList ); > > > > +) There were question in the mailing list about prepared statements > and a > > lot of statement parsing within Oracle. I'm not pretty good at > database > > and my last encounter with ODBC/JDBC is long and happily forgotten. > But > > looking at the BasePeer.java I think what could be the reason for that > > behaviour mentioned above. A conenction is taken from the pool, a > prepared > > statement is created from this connection, the query is done and at > the > > end the statement is closed. AFAIK these forces the database to do the > > same parsing for the next prepared statement again. > > > > Does it make sense to store the prepared statement and all the > information > > needed to create it into a result returned from > > BasePeer.createPreparedStatement()?! The prepared statement could be > > reused, if the connection is broken the prepared statement could be > > recreated using a good connection and most of the parameter handling > is > > already there?! Am I completely on the wrong track?! > > > > Thanks in advance, > > > > Siegfried Goeschl > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org > > For additional commands, e-mail: torque-user-help@db.apache.org >=20 >=20 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org > For additional commands, e-mail: torque-user-help@db.apache.org >=20 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org > For additional commands, e-mail: torque-user-help@db.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org For additional commands, e-mail: torque-user-help@db.apache.org