[DB-SIG] Optional DB API Extensions

[M.-A. Lemburg]

Stuart Bishop wrote:
> 
> On Wednesday, October 24, 2001, at 01:04  AM, M.-A. Lemburg wrote:
> 
> > Title: Optional Database API Extensions
> 
> I would call this DB API 2.1 to avoid confusion, or if all the
> methods do end up being optional, simply updating the existing
> DB API 2.0 PEP. 

This is what my plans is (to update the DB API 2.0 PEP).

> I think it is important that the current
> specification ends up in a single document, as opposed to being
> split up into two separate PEP's.

Right.
 
> I also would like the connection method:
>          quote(object)
> 
>              Returns a SQL quoted version of the given variable as a
>              string, suitable for execution by the database backend.
>              For example:
> 
>                  >>> print con.quote(42)
>                  42
>                  >>> print con.quote("Don't do that!")
>                  'Don''t do that!'
>                  >>> print con.quote(time.time())
>                           TO_DATE('01-Jan-2001 12:01','DD-MMM-YYYY H24:MI')

Hmm, why would you need this ? The database module will apply
the needed quoting for you if you use bound parameters (which
is strongly encouraged).
 
> I'd also add cursor methods for Python 2.2 iterators:
> 
>          next()
> 
>              Return the next row from the currently executing SQL
> statement.
>              A StopIteration exception is raised when the result set is
> exhausted.
>              This method will raise a NameError exception if run under
> versions of
>              Python earlier than Python 2.2.
> 
>          __iter__()
> 
>              Returns self.

Good idea.
 
> Another optional method may be a call to have the fetchXXX methods return
> dictionaries rather than sequences, as this seems to be a common
> extension
> and feature request.

Bad idea ;-) 

There are plenty tools out there to turn the tuples into dictionaries.
The dictionary approach also has some drawbacks, e.g. what to do about
columns which are calculated rather than fetched from a database
table.

I'd rather leave this to (simple to write) tools which take
the standard output and turn it into whatever the application
wants/needs (e.g. dictionaries, instances, lists, etc.).
 
> Is it worth adding the transaction isolation level stuff I outlined in
> the DB API 3 strawman I put out a month or two ago? There didn't appear
> to be much interest in these, but I may be wrong. (I will be getting
> around to replying to the last round of comments on  the 3.0 strawman
> soon, as I have spare time again as of today).

The problem I see with these kinds of additions is 
that there are dozens of different capability options which may or 
may not be useful to DB API users and adding a new attribute or 
method for each and every one of them doesn't seem like the right
approach.

mxODBC has a few .getXXXoption() style methods which allows
retreiving this information from the database. I don't think we
can come up with a standard extension here, though.
 
> Anyway, the proposal seems good from my point of view. Thanks for
> the effort :-)

Thanks,
-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/