|
⇤ ← Revision 1 as of 2003-02-18 10:42:24
Size: 941
Comment:
|
Size: 1491
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 20: | Line 20: |
| Prepared statements in addition to Connection and Cursor. | 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 |
| Line 28: | Line 30: |
| Should the argument passing be driver dependent, should there be additional methods, should only one be allowed? |
|
| Line 29: | Line 33: |
= 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 |
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.
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