db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: Will migrating from 3.0 to 3.3 help me?
Date Tue, 30 Sep 2008 07:36:39 GMT
> Hi, I am just starting maintenance work on a project
> built with Torque 3.0 on top of PostgreSQL.
> I'm considering migrating to 3.3 but thought I would
> check a couple of things here first.
> The first thing I noticed was the huge difference in performance
> using different versions of JDBC drivers.  Older versions
> (e.g., pg74.216.jdbc3.jar) work well; newer ones (e.g.,
> one I tried for PostgreSQL 8.2, postgresql-8.2-506.jdbc3.jar) don't.
> The difference is staggering - a set of queries that takes 10 seconds
> with an old driver takes over 90 seconds with a newer
> driver.
> I ran a trace on the code and found out what's going on - the Column
> class in the village library does lots of requests on metadata.
> In the old JDBC driver, these calls are not implemented;
> in the newer drivers, they are, and there are now
> 12 - yes, twelve! - extra database queries being generated
> for each original query.
> I notice a Sybase user has already reported this at:
> http://issues.apache.org/jira/browse/TORQUE-36
> Question 1: is this now addressed in 3.3 or in SVN?

No., I am afraid not. There is agreement in the Torque dev community that 
we want to get rid of village but unfortunately, nobody had the time to do 
it yet.
> Question 2: if yes, how do I go about migrating?
> In my case, the previous developers made substantial
> modifications to 36 of the generated Java files.
> Please tell me there's a better way than copy/paste
> the changes into the new generated files.

I am not sure how Torque 3.0 works. In Torque 3.3 there are two generated 
classes: one base class which is always generated and one empty class 
which inherits from the base class which can be changed by the developer 
and which will not be overwritten once it exists. Your hand-written code 
should go into the latter class.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message