[DB-SIG] Last round for DB API 1.1
Thu, 18 Mar 1999 02:44:52 -0800
M.-A. Lemburg wrote:
> · What to do about Andy Dustmans proposal to have .rollback()
> raise an exception in case transactions are not supported by
> the database ?
This seems almost closed now...
> · Andy Dustman also asked for a standard way to find out the
> parameter marker syntax used by the database.
> There are at least two possibilities:
> ?,?,? in the order of the given parameters
> :1,:3,:2 in any order only referring to the parameter position
> Not sure how to get this information into a constant or a method...
> Any ideas ?
I think it behooves us to have a way that a module can state *which* it
uses, but we don't *require* a specific format.
I will suggest that we add a module global named "paramstyle" with the
'qmark' -- question mark style
'numeric' -- numeric, positional style
'named' -- :name style
'percent' -- ANSI C printf format codes
'xpercent' -- Python extended format codes (e.g. %(name)s)
However, we should also note that the API does not have a mechanism for
named parameters. That obviates the 'named' and 'xpercent' styles at the
Anyways: having this global will allow a higher-level module to do
> · Should we add additional constructor signatures to the API spec ?
> So far we have Raw,Date,Time,Timestamp. Maybe we should rename
> Raw to BLOB or Binary to be in sync with SQL ?! What about a
> monetary constructor... does anyone have experience with such
> types ?
Per later emails, the Raw was renamed to Binary.
I disagree with the need for seperate Date, Time, and Timestamp. I am
unaware of an occurrance where the difference was needed. For the past
three years, dbiDate() was sufficient, so I question the need for three
Note: aliases for dbiRaw, dbiDate are not needed since those were names
in the "dbi" module, not the database module.
> · We still need to settle the sequence of sequence problem
> with .execute().
> Since e.g. ('abc',) fits this definition but surely isn't intended,
> we'll need some other way to handle sequences of parameter/data
> sequences. How about depreciating the use of those lists in
> .execute() and defining a .executemany() method for this purpose
> instead ? Other ideas ?
Ah. I like executemany() (better than my insert() suggestion). I'll vote
for this, with the associated deprecation of passing a seq-of-seq to
Greg Stein, http://www.lyra.org/