(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:[EMAIL PROTECTED]]
> 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-> [EMAIL PROTECTED]>
>
> For additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
