[DB-SIG] SQL statement parse for Oracle

[M.-A. Lemburg]

"Dittmar, Daniel" wrote:
> 
> Jekabs Andrushaitis wrote:
> > > In the Oracle world SQL statement parsing can take
> > considerable CPU/Block IO
> > > for complex statements.
> 
> > From: M.-A. Lemburg [mailto:mal@lemburg.com]
> > Perhaps I should add a .prepare() method to the set of standard
> > DB API extensions though ?!
> 
> Would it be useful to give an option to the cursor () method that statements
> for this cursor should be cached by the connection?
> - at least with connection pools, it is much easier to have the connection
> object handle the statement cache instead of managing a pool of
> <JDBCSpeak>PreparedStatements</JDBCSpeak>
> - I'm somewhat reluctant to cache ALL statements as some programmers tend to
> build complete INSERT statements rather than using parameters.
> 
> The current strategy with the SAP DB implementation is to reuse the parse
> information if the SQL string hasn't changed since the last execute (),
> statements without parameters are executed without a prepare step. This
> works reasonably well for the sane case of using one cursor for only one
> purpose, but fails in the case of connection pooling.

I'd suggest to add a writeable attribute .cacheable to your 
implementation... I don't think that adding all this to the 
DB API spec will really help since even the .execute() statement
caching is optional.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/