[DB-SIG] Optional DB API Extensions

Federico Di Gregorio fog@debian.org
25 Oct 2001 13:11:10 +0200

Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2001-10-25 at 12:52, 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. 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.

i continue to think we need two pep, one for the official dbapi (2.0,
2.1, 3.0, etc.) and one for the =20
> 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())

this is, imo, wrong. you can expect quote() to be able to cope with
*any* object. lets stick to the dbapi official types:

	>>> print con.quote(module.TimestampFromTicks(time.time()))=20
        TO_DATE('01-Jan-2001 12:01','DD-MMM-YYYY H24:MI')

> I'd also add cursor methods for Python 2.2 iterators:
>          next()
>              Return the next row from the currently executing SQL=20
> statement.
>              A StopIteration exception is raised when the result set is=20
> exhausted.
>              This method will raise a NameError exception if run under=20
> versions of
>              Python earlier than Python 2.2.
>          __iter__()
>              Returns self.


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

but we need dictionaries able to cope with multiple equal keys (some db
allow multiple columns with the same name). also, should the keys be
compared ci or cs?

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

i am working on this for psycopg. it is somewhat simplier that your
proposal, just a way to ask the db for a given isolation level. or are
isolation levels defined at the SQL standard level?


Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
INIT.D Developer                                           fog@initd.org
  Debian. The best software from the best people [see above]
                                      -- brought to you by One Line Spam

Content-Type: application/pgp-signature

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org