[PYTHON DB-SIG] Python Database API

Greg Stein gstein@microsoft.com
Wed, 16 Apr 1997 03:05:41 -0700

I don't know of any implementation of callproc(). I believe minor
changes to the ODBC module (if they're even needed) would support stored
procedures via execute(). I believe the same for Informix. I'm not
familiar enough with the Oracle one whether it could be done (I do
believe we did it with ODBC and Informix, however).

DBI can be independent. The question is what sort of utility it might
have outside of the DBAPI. It's only real purpose is to provide more
type information to the database module for binding the values. For
example, a python string can be a VARCHAR or a LONG RAW... Oracle
*requires* that it be bound appropriately... the only way to provide
that type info is with something like the DBI wrapper. We went through a
number of options that would be a bit more declarative, but it made the
API overly complex and tossed them; the DBI approach seemed easiest and
straight-forward. However, since they are merely wrappers for typeinfo
provision, they don't lend much utility outside of the DBAPI.

The ODBC modules does work outside of Windows. I recall a post or two to
the main Python list with patches and/or info of what needed to be done
to make it work under Unix. I seem to recall that the SOLID module is a
derivation of the ODBC module.

I'm the HTML keeper, the list members are the owners of the API. Feel
free to email the HTML to the list and I'll get it uploaded (along with
some other changes that I need to do).


	-----Original Message-----
	From:	Anthony Baxter [SMTP:arb@connect.com.au]
	Sent:	Tuesday, April 15, 1997 10:47 PM
	To:	Greg Stein
	Cc:	'Mona E. Gamboa'; db-sig@python.org
	Subject:	Re: [PYTHON DB-SIG] Python Database API 

	>>> Greg Stein wrote
	> Hmm. I thought there was a spec for DBI (just checked... there
is, but
	> it doesn't cover the "generic" exceptions). Personally, I have

	I will document what I've done, and add it in.

	I'd _like_ to see dbi become a seperate module, so we can share
	code across all who use it. I'm just not sure how independant it
can be.

	> I would say that any cursors associated with a closed
connection become
	> unusable. Closing cursors should not have an impact on the

	Yep. This should go into the API.

	> I've never dealt with callproc. In truth, I'm not positive
that it is
	> needed after all. It seems to be quite possible to simply use
	> for store procedures in addition to (SQL) statements.

	Ok, well, is _anyone_ using it? If not, can we drop it from the

	> One interesting note: the ODBC module is apparently quite fast
	> relatively to other mechanisms available to Python for
	> databases (e.g. ADO). You can *make* ADO go faster, but it
takes a good
	> amount of fine tuning and voodoo. Empirically, the ODBC module
is simple
	> to use (love that API!) and capable of being quite efficient.

	I suspect that most of the database modules can be given quite a
	dose of go-faster-stripes, and made quicker. Does ODBC work on

	> To fetch/insert more than one row at a time, are you using the
row count
	> from fetchmany() and/or the arraysize attribute?

	At the moment you set the cursor.arraysize, then call
fetchmany(None). I've
	got to add code to fetchmany() to change the arraysize - it will
end up that
	curs.arraysize = 10
	will set curs.arraysize to 100. Doing a repeated fetchmany()
with the same
	number of rows will have the same effect as setting arraysize
manually - 
	it won't have to reallocate space internally, so should be

	Does someone "own" the API, or should I just make changes to the
HTML and
	mail it to the db-sig list?


	DB-SIG  - SIG on Tabular Databases in Python

	send messages to: db-sig@python.org
	administrivia to: db-sig-request@python.org

DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org