[DB-SIG] Last round for DB API 1.1

[Greg Stein]

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
following values:

'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
moment.

Anyways: having this global will allow a higher-level module to do
something intelligent.

> · 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
varieties here.

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

Cheers,
-g

--
Greg Stein, http://www.lyra.org/