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.)

TableOfContents

Prior Art

• Stuart Bishop posted a DB-API 3.0 strawman in 2001, which can be found on the Aug2001DbApi3Strawman page.

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?

Refined transaction model

Currently, DB-API 2.0 loosely defines transactions at the level of a connection. However, many drivers provide extensions that allow multiple (distinct, nested, or both) transactions to exist on a given connection. Maybe it is time for a next generation DB-API to better formalize the transactional scope of a connection. Backends and drivers that wish to allow multiple concurrent transactions will have to implement a simple connection pool so that the same physical connection can be shared by multiple logical DB-API connection objects. Of course, this alters the concept of a connection and may require even more infrastructure to support. i.e., a developer could request an unshared connection so that global (physical) connection variables can be changed in isolation.

Also, some thought should be directed towards properly handling the semantics of nested transactions, as more and more backends are now supporting them.

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