[DB-SIG] Last round for DB API 1.1

[M.-A. Lemburg]

Hi everybody,

Thanks for all your comments on the 1.1 DB API specification update
so far.

There are still some open questions which need to be discussed
prior to the final call:

· What to do about Andy Dustmans proposal to have .rollback()
  raise an exception in case transactions are not supported by
  the database ?

IMHO, we should leave the situation as it is: some DBs do not
support transactions (e.g. MySQL), some do but you can turn
transactions off (e.g. this is the ODBC default)... all in all
its a feature that is very dynamic, specific to connections.

If the API were to raise an exception in case tranactions are
not supported, the underlying interface would have to query the
current state prior to every .rollback() and even prior to garbage
collecting the connection object -- at a time where there could
be no connection available any more. 

The only way I see to support this "capability" feature is to
define a standard method for querying capabilities in general,
e.g. .capability('transactions'), but that would introduce a set
of constants which would also have to go into the spec... or
maybe a set of methods .has_this() and .has_that()... I'm not sure
whether it's worth defining these things in the spec at all:
e.g. switching from a database with transaction to one without
them is hardly doable in case your code needs them.

· 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 ?

· 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 ?

· 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 ?

Cheers,
-- 
Marc-Andre Lemburg                               Y2000: 289 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------