[DB-SIG] SQL statement parse for Oracle
Anthony Tuininga
anthony@computronix.com
Fri, 14 Dec 2001 10:31:24 -0700
Ok, that sounds reasonable. I have one question, though. Is the last
".command" meant to be ".statement"? In other words, is the statement
that is prepared stored with the cursor and then also passed to the
execute function? Like this?
cursor.prepare("SQL")
cursor.execute(cursor.statement, parameters)
If that is what is intended, I can live with that as there is a simple
pointer comparison in order to determine if the statement ought to be
parsed or not.
Anthony
M.-A. Lemburg wrote:
>Jekabs Andrushaitis wrote:
>
>>In the Oracle world SQL statement parsing can take considerable
>>
>CPU/Block IO
>
>>for complex statements.
>>...
>>What I am talking about is API to allow to parse statement for a
>>
>cursor (for
>
>>Oracle
>>OCI it is done by 'oparse' calls) without executing it. It could be
>>
>used to
>
>>speed
>>up things in situation where same statement has to be executed several
>>
>times
>
>>with different bind variables for example.
>>
>
>This is already possible using the .execute() command cache which
>is described in the DB API.
>
>>Or when you want application uses
>>persistand DB connection and you can create several cursors for each
>>operation
>>you need to perform thus eliminating cost of parsing each statement
>>
>over and
>
>>over
>>again...
>>
>
>See above.
>
>The only problem is that you have to execute the statement at least
>once to get it prepared on the cursor. This isn't much of a problem
>though if you wrap the DB API cursor objects in more elaborate
>Python objects (for abstraction purposes or to extend them with
>new features you need).
>
>The reason for not putting this into the DB API is that some
>DBs may not be able to separate the prepare and the execute
>steps, e.g. some ODBC drivers only pretend to prepare the
>statement -- the actual parsing etc. still takes place at
>.execute() time.
>
>Perhaps I should add a .prepare() method to the set of standard
>DB API extensions though ?!
>
>Here's what I have in mxODBC:
>
> .prepare(operation)
>
> Prepare a database operation (query or command) statement for
> later execution and set cursor.command.
> To execute a prepared statement, pass
> cursor.statement to one of the .executeXXX() methods.
> Return values are not defined.
>
>and
>
> .command
>
> Provides access to the last prepared or executed SQL command
> available through the cursor. If no such command is available,
> None is returned.
>