[DB-SIG] Re: [PyGreSQL] Version 3.0 PyGreSQL
Greg Stein
gstein@lyra.org
Thu, 11 May 2000 15:00:12 -0700 (PDT)
On Thu, 11 May 2000, Jeremy Hylton wrote:
>...
> BT> A DBI cursor doesn't have to map to a real
> BT> database cursor. The existance of the cursor is just a way to
> BT> allow a speration between a database connection, and individual
> BT> statements on that connection, as some databases allow you do
> BT> do. IIRC
>
> It would be helpful to have a high-level mechanism to use real DB
> cursors.
Um... there is. The DBAPI allows for real DB cursors. Did you mean
something else?
> I needed them for an application that was scanning a very
> large table. Without a cursor provided by the DB, the pgsql library
> copies the entire table out of the database; then the pgsqldb module
> copies the entire table into a Python objects.
Poor implementation. The DBAPI is designed around true cursors, so pgsqldb
should use that design.
I believe the problem may be that pgsqldb was designed against an older
PostgreSQL, which didn't have cursors.
> >> Does the DB spec have an author? Is this the right place to ask
> >> questions? (I realize there are lots of reason for questions to
> >> go unanswered.)
> >>
>
> BT> MA Lemburg was the main driving force behind the v2.0 DBI spec.
>
> BT> WRT the autocomit issue, ODBC also starts in autocommit mode as
> BT> well. This is probably one fo those you like what you know
> BT> questions. There are arguments on both sides of the issue.
>
> It's fine for it to be a "know what you like" issue, except that there
> isn't any standard way to put yourself in the other mode. There ought
> to be an autocommit flag to the database connection and a
> beginTransaction method.
The specification states that autocommit must be OFF by DEFAULT. That is a
solid definition, and all DBAPI-compatible modules obey that. Bill was a
bit misleading there :-)
Turning autocommit on/off is performed in a module-specific manner. It is
not part of the DBAPI spec.
beginTransaction is implied by issuing a statement. The transaction ends
when you call .commit()
> Are there any other issues outstanding that would lead to a third
> version of the API?
Not really. A few here and there. Dunno if anybody has been collecting
them.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/