db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walt Armour <Wa...@concur.com>
Subject RE: [PATCH] Fix Torque doUpdate method to not perform SELECT befo re UPDATE
Date Wed, 15 Jan 2003 19:53:22 GMT
(Totally pointless and with no weight whatsoever) +1

We've looked into this code ourselves (but have not yet reached the point in
development where we need to replace it).  While I can't speak for this
explicit example/patch I can assure you that from a performance standpoint
this should gain us far more than 1% for any sizeable query.  For an update
that would hit 500 rows, the existing code will generate 501 separate
queries.  The patch will generate 1.

It's the difference between:
---
select * from table where foo = true;
foreach (row) { rowobj.value = newvalue; rowobj.save }
---
and:
---
update table set value = newvalue where foo = true;
---

The benefits should be obvious just in the reduced queries and network
traffic to the DB (if across the network).

I would gladly help work this into the 3.0 line.


> -----Original Message-----
> From: Martin Poeschl [mailto:mpoeschl@marmot.at] 
> Sent: Tuesday, January 14, 2003 1:08 PM
> To: Turbine Torque Developers List
> Subject: Re: [PATCH] Fix Torque doUpdate method to not 
> perform SELECT before UPDATE
> 
> 
> 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 rejected.
> >
> >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 API.  
> >
> >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
> >  
> >
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:turbine-torque-dev-> unsubscribe@jakarta.apache.org>
> 
> For additional commands, 
> e-mail: <mailto:turbine-torque-dev-help@jakarta.apache.org>
> 

Mime
View raw message