db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramesh Sabeti" ...@reazon.com>
Subject RE: Torque 3.1 and Prepared Statements ....
Date Tue, 02 Dec 2003 18:00:56 GMT
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.
 
> 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√ľ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
> use.
> 
> 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,
> 
> Ramesh.
> 
> > -----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
> 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 = 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
> 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message