[DB-SIG] SQL statement parse for Oracle
Anthony Tuininga
anthony@computronix.com
Fri, 14 Dec 2001 11:05:46 -0700
Sounds good to me. Note that the DB API document currently specifies
"operation". Perhaps this attribute can be called "operation" or we can
change the documentation?
And does anyone else have any comments? I can implement this in
cx_Oracle as well, thus creating a default standard, but I would prefer
to have this changed in the API if at all possible.
Anthony
M.-A. Lemburg wrote:
>Anthony Tuininga wrote:
>
>>Ok, that sounds reasonable. I have one question, though. Is the last
>>".command" meant to be ".statement"?
>>
>
>I called it .command because the SQL you execute is not always a
>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)
>>
>
>Yes, that's the idea. This is needed in order to make the whole
>thing compatible to the .executexxx() methods.
>
>
>>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.
>>
>
>Right, that's the idea -- you sort of reuse the .execute() caching
>idea for separating the two steps.
>
>
>>M.-A. Lemburg wrote:
>>
>>>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.
>>>
>