[DB-SIG] Towards a single parameter style

[M.-A. Lemburg]

Kevin Jacobs wrote:
> Now that I have thought about it more, the above
> would read better as:
> 
>    connection = connect(...)
>    command = connection.prepare(sql)
>    cursor = connection.cursor()
>    cursor.execute(command, (arg1, arg2, arg3))

FWIW, this doesn't work with ODBC where statements and cursors
are more or less identical beasts. You can prepare the statement
on a cursor, but not separately. I believe that many database
backends implement this kind of strategy, otherwise it's hard
to see why this implementation style was chosen for ODBC.

The only reason to make preparing explicit would be to prefill
a cursor cache. It is already possible to do in lazy mode after
you have executed the statement at least once, since the DB API 2.0
suggests that the cursor reuse the previously prepared statement
in case the same statement string is passed in again.

You should also note that preparing a statement can well be
implemented as noop by the database driver. ODBC drivers like
the MySQL driver implement preparing this way, since all the
parsing is done on the server side. I'm sure many others do
the same, so caching the prepared statement does not necessarily
give you a performance boost.

And finally: things like connection pooling, cursor pooling
and statement management are something for abstraction interfaces
to implement not the DB API driver. It is much better to do
it this way, since the abstraction can be tuned to the application
needs.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Software directly from the Source  (#1, Feb 19 2003)
 >>> Python/Zope Products & Consulting ...         http://www.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
Python UK 2003, Oxford:                                     41 days left
EuroPython 2003, Charleroi, Belgium:                       125 days left