db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Göschl,Siegfried" <Siegfried.Goes...@drei.com>
Subject AW: Torque 3.1 and Prepared Statements ....
Date Tue, 02 Dec 2003 17:44:38 GMT
Hi Ramesh,

1)) I can definitely patch the Velocity Templates to do the automatic conversion from Village
Records to Torque classes

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.

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?!

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 ... :-)

Maybe someone can team up with me and with a little bit of help we can fix the thingies.

Thanks in advance

Siegfried Goeschl

PS: Eric and Martin, would you give me a hand in testing changes I make/made?!

-----Ursprüngliche 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 ....

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 :).

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

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.

Hope it helps,


> -----Original Message-----
> From: Göschl,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
> To ensure that Torque is doing well I wrote a regression test suite
> works fine. The last addition was testing of Prepared Statements which
> showed a few problems
> +) The current implementation returns a List of VillageRecords. Is
> any reason why not to generate code which does the following
> automagically
> Foo.addSelectColumns( criteria );
> ... more criteria wrestling ..
> List recordList = FooPeer.doPSSelect( criteria );
> List result = 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
> and my last encounter with ODBC/JDBC is long and happily forgotten.
> 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
> statement is created from this connection, the query is done and at
> 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
> 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
> 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

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

View raw message