[DB-SIG] Preparing statement API
Thu, 27 Jan 2000 17:28:47 +0100
Greg Stein wrote:
> On Tue, 25 Jan 2000, M.-A. Lemburg wrote:
> > Not all that different and without the need to invent new
> > APIs or objects... seriously, all these gimmicks can be done
> > using abstraction layers on top of the existing DB API interface.
> This was the specific intent behind the current design. An unsophisticated
> provider (or database) need not worrying about caching, reuse,
> preparation, or implementing additional methods. The provider can add the
> reuse functionality and performance will increase.
> On the other side, a client can code with the understanding that reuse can
> occur, but it will continue to work for those providers that do not
> provide the functionality. It also eliminates feature testing.
> The design lowers the bar for providers, reduces the breadth of the
> interface, yet provides a smooth upgrade path for more performance.
> As with most of the design of DBAPI, it provides a simple/minimal
> requirement on the provider implementor, a not-broad interface for the
> client to worry about, and provides for more sophisticated layers of
> functionality at the Python level.
All true. Still, Hrvoje has got a point there: currently
it is not possible to prepare a statement for execution
(without actually executing it). This is needed in case
you plan to have one cursor per (often used) statement and
store these in a cache of your database abstraction
Therefore, I propose to add the new features I mentioned in a
previous mail (cursor.command and cursor.prepare()) to the next
release of the DB API spec.
Interface modules not having access to the prepare step of the
DB can then implement cursor.perpare(cmd) by simply setting
cursor.command to cmd and leaving the actual parsing and
prepare step to the execute method as is currently done.
Python Pages: http://www.lemburg.com/python/