This page should summarize topics for the DB API 3.0. It is meant to provide
- clarifications of the DB API 2.0
- new optional features
- new recommendations
A related page is ExtendingTheDbApi, which lists features that aren't general enough to make it into the spec.
Discussions should be held at db-sig@python.org, with summaries (even preliminary ones) entered here. This is also the place where limits imposed by the underlying database/library implementation should be entered for further reference. It could also be used as a place for technical voting by the driver authors (with tags like 'personal preference', 'trivial to implement', 'difficult to implement', 'implementable only with loss of performance' etc.)
Unified Parameter Style
Possibilities
- currently: one parameter style per driver
- one parameter style for all drivers
- multiple parameter styles per driver, switchable per Connection, Cursor or .execute ()
Additional Driver Objects
Prepared statements in addition to Connection and Cursor. Related is the idea of statement caching:
- Cursor object as a prepapared statement
- Cursor object accesses a pool of cached prepared statements
Parameter Passing
cursor.execute ("SELECT where size = :size", {'size': localvar}) vs.cursor.execute ("SELECT where size = :size", size = localvar)
cursor.execute ("SELECT where size = ?", [localvar]) vs. cursor.execute ("SELECT where size = ?", localvar)
Should the argument passing be driver dependent, should there be additional methods, should only one be allowed?
Schema Information
Role of the DB API spec
- programs should be completely portable, including the SQL
- programs should be portable at the API level
- it should be possible to write portable programs, but extensions are allowed
- why bother, real apps write their own higher level API
Common Modules
- unit tests