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