Ok, I am back, let's continue...

On Fri, Aug 24, 2007 at 04:12:03PM -0500, Kevin J. Rice wrote:
> Important point #1:  PREPARED STATEMENTS EXECTUTE SIGNIFICANTLY FASTER than
> parsed ones

   Yes, prepared statements by itself should be faster, but you are going to
change SQLObject._init() which is used in all creation and retrieval
operations. And the change is rather big:

> Pseudocode:
> - come up with the prep'd statement's name, 
> - try to execute it;
> - if that doesn't work:
>       - destroy anything by that name, 
>       - try to recreate it, 
>       - try to run it again, and 
>       - if that doesn't work:
>               - failover to the old way.

   Are you sure SQLObject in general will not suffer significant
performance decrease?

> Oleg, I'm confused by your mentioning converting different types in 
> different databases.

   With the code in my private branch I have tried to solve much more
generic problem - to make all SELECT/INSERT/UPDATE/DELETE statements to use
DB API bound parameters:

      cursor.execute("SELECT * FROM atable WHERE id=?", id)

   That's a different goal from using PREPARE/EXECUTE.

> The issue I'm concerned with on different databases is the fact that 
> some might have a "prepare" syntax that's different from others.  But, 
> I'll worry about other databases once there is a working prototype.

   That difference have to be processed in concrete connection classes
like PostgresConnection; see how LIMIT/OFFSET and other backend-specific
issues are encapsulated in the connection classes.

   And final note - if your aim is only to speed up joins try SQL*Joins
classes (SQLMultipleJoin, SQLRelatedJoin) - instead of iterating over
"SELECT id FROM join" they construct a proper SelectResults which is faster
(one query for a join) and more correct (orderBy is implemented in SQL
instead of Python).

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            [EMAIL PROTECTED]
           Programmers don't die, they just GOSUB without RETURN.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Reply via email to