db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Poeschl <mpoes...@marmot.at>
Subject Re: [PATCH] Fix Torque doUpdate method to not perform SELECT before UPDATE
Date Tue, 14 Jan 2003 21:07:31 GMT
any performane test  results you can share with us??

if we really can boost performace that way i'm +1 for the change .. if 
we just win 1% i don't think the changes are worth the work needed

Chris Felaco wrote:

>(sorry for wrong posting on turbine-dev)
>I'm sending this mainly for illustration of what I'm proposing we do with Torque to improve
performance and maintainability.  I've tested this in my environment and will soon be trusting
it in my production environment.  The changes are based on the Turbine 2.1 code base which
I'll be forced to continue to use for a while.  I'd be happy to work the code into the 3.0
code base if the patch will be accepted, but I can't afford to spend the time if it will be
>Basically what I've done is stolen the part of the Village API that Torque really needs
and used only that.  The new SqlValue class I am adding is really just the village.Value class
with expanded privileges, and new constructors.  This new class can be used for PreparedStatements
and processing ResultSets throughout the BasePeer class, without using the entire Village
>Perhaps an even better solution would be for the Criteria to use SqlValue objects internally
so that when you add a clause to the Criteria it would determine the SQL type of the parameter
right then.  The Critera code would have the opportunity to raise an exception if the supplied
value cannot be converted to the necessary SQL type.  Then errors can be caught before the
actual select or update operation is performed and traced back to real culprit more easily.
>At the moment, the only part of the Village API that doUpdate uses is the Schema class,
simply because it caches table meta-data for us.  The code to replace this could possibly
be added to the Map classes.
>- Chris

View raw message