[DB-SIG] ANN: mxODBC Version 0.3

[Greg Stein (Exchange)]

Bill makes some good points, but the one single thing that caught my eye
last week when you first announced this was your tossing of the DBI
module. I'd like to reiterate that that was really not a very good idea
(IMO).

Exceptions are handled by identity. The single dbi module provides the
exception that all db modules will raise. Clients can then catch
"dbi.integrityError" and catch an error regardless of what underlying db
module was used. The dbi module also provides a common set of type
information.

As with Bill, I don't understand some of the motivation here...

-g

p.s. I gave up championing the db-sig because I believe there was
nothing left for it to do... that it was a SIG without a purpose. I'd
propose that creating a uniform ODBC db module should be placed on the
agenda. There was also an "open item" on the agenda for somebody to
update/maintain the DBAPI spec; that is still open/undone.

-----Original Message-----
From:	Bill Tutt 
Sent:	Friday, November 28, 1997 3:43 PM
To:	'M.-A. Lemburg'; DB-SIG @ Python.org
Subject:	RE: [DB-SIG] ANN: mxODBC Version 0.3

Ugh.. why do we need N different ODBC modules?
I'd really love to know.. 

>From your webpage:
	This interface module was created in need of an Python interface
to
the German ADABAS D relational database from Software AG. This database
can
be accessed through the Oracle CLI and or ODBC. After having tried both
the
OracleDB module from Digital Creations and the SolidDB Module (ODBC)
from
g.a.m.s. I decided to code my own version, because both didn't meet my
requirement for high stability for various reasons. 

What are those reasons?
Please, we'd like to know, really.. :)

Also, whats wrong with just porting the ODBC code from Win32?
I'm certainly more than willing to answer specific questions about it.
Unfortunately I don't have the time to test fixes to it, but I'm more
than
happy to answer questions about it.

Lets see if I can list the differences between your ODBC code, and the
Win32
version..
Win32 version has exceptions, where you have essentially ODBC errors..
Exceptions: The dbi code includes exceptions your ODBC module is
supposed to
throw..
                   Specfically: noError, opError, progError,
integrityError,
dataError, and internalError
Where they apply to the following cases:
	noError is generally ment to be thrown when you have a warning
i.e.
Data truncated that you should know about.
	opError is an operational error i.e. being disconnected,  data
source name not found, etc....
	progError is a programming error i.e. table already exists,
table
not found, etc...
	integrityError is an integirity error in the database's
relational
integerity i.e. a foreign key check fails
	dataError is a data error, i.e. Numeric value out of range,
division
by zero, etc...
	internalError is an interntal Database error, i.e. Invalid
cursor
state, invalid transaction state, etc...

You have: (sqlstate, sqltype, errortext, lineno) tuples.
You can find the sqlstate->DBI exceptions in odbc.cpp in the Win32 code.

Autocommit: You default to off, when ODBC defaults to on.. 
This is highly conterintuitive, and violates the principle of least
surprise.
The Win32 code has a similar function: setautocommit(0 | 1) to turn
autocommit on or off.
Whether or not ODBC should default to autocommit or not isn't really the
question.. if it does, so should we.

Connection String:
You have ('host:DBNAME', 'uid', 'pwd')
Win32 has: 'DSN/uid/pwd'
What really should be done here is to adopt an ODBC like connection
string... aka:
'property=value;property=value' Where "uid" is always the userid, and
"pwd"
is always the password.

fetchxxx() return values:
The return values are the same as the Win32 ODBC code

Ditching DBI:
That was a particulary silly thing to do, the exceptions listed above
exist
in DBI, and DBI is a useful abstraction mechanism, and is database
independant.. Why does it need to be tossed?

Large Binary/Text data:
This is one place where your code does the right thing, and the Win32
ODBC
code falls down.
Currently the Win32 ODBC code has a 64k limit on binary data, which can
be
easily fixed.

Dates:
Well there isn't any difference between what you do, and what the
DBI/Win32
ODBC code does.
(Well except for handling TIME types but thats just a function of
ignoring
the date part, or indeed just one line in odbc.cpp)
They're both limited to dates after Jan 1, 1970 00:00:00 GMT.
What we should do is come up with a sane date type for Python that isn't
based on time_t.

Looping over lists of tuples for non-resultset producing queries:
Your code does do this, and modifying Win32 ODBC to do this is trivial
as
well. (I have the necessary details btw...)

ODBC Catalog functions:
Well your code is ahead of the Win32 code here obviously since the Win32
code doens't have anything like this.
Submission of code for this kind of thing is greatly appreciated.

Wanting only to have one ODBC module,
Bill Tutt
billtut@microsoft.com
Not speaking for Microsoft, etc...


_______________
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
_______________