[DB-SIG] Remaining issues with DB API 2.0

Andy Dustman adustman@comstar.net
Wed, 31 Mar 1999 13:46:33 -0500 (EST)


eOn Wed, 31 Mar 1999, M.-A. Lemburg wrote:

> To make testing for "multiple result sets supported" possible,
> I think this API should be an optional method like .rollback:
> either not be defined (giving an AttributeError) or raise
> a NotSupportError... which brings us to the next point ;-)
> 
>  Should we add NotSupportedError as subclass of OperationalError ?
> 
>  Is there a strong need for "capability testing" other than using
>   hasattr() ?

I have no objections to making it an optional method. As for other
capability testing, I need to think that any program that relies upon some
capabilty to function is simply going to break (hopefully in an obvious
way) when it uses a database which doesn't have the capability in
question.

For example, if I have an application which depends upon rollback() being
there, and I move my application to a database with no rollback(), it
should fail in such a way that I become clueful that there is a problem. I
then need to redesign my application. Hopefully if I've done the design
properly, I can make a subclass which doesn't depend on the feature in
question.

All of which leads us back to connect(), which we have now established
(yay) is completely database-dependent, so we acknowledge that interface
can't cover everything, which is no real embarassment. This really means
that there should be some design principles involved in writing database
applications.

For another example: I do have an application (which does in fact use
rollback()) that I am moving from ODBC.Solid to MySQL, which of course
doesn't have it. The design is such that I have a couple of abstraction
layers between my application and the actual database interface. The
important part of this is that I have a specialized API for my schema. It
wraps a connection object and adds various methods to do specific queries,
passing in and returning objects. (There's actually a layer between this
and the database interface that converts between my objects and suitable
query parameters/rows.)

The result of this is, I really only have one module in the system that I
have to modify. If I really wanted to, I could make a new module (or
convert to a package) and subclass only a few methods to make it
compatible with the new database. But then, I shouldn't be depending on
either hasattr() for capability testing; I should RTFM. Some rewriting
when switching databases is going to be inevitable, even if I'm using the
same interface (i.e. mxODBC).

This should not actually be part of the specification, but perhaps we need
a design note, or guidelines for designing applications so that they can
ported between different databases with a minimum of effort. This makes
your application more resilient to changes in the DB API as well (though
it's hardly affecting my application, if at all, and the API shouldn't
change much more in the future).

-- 
Andy Dustman  (ICQ#32922760)    You should always say "spam" and "eggs"
ComStar Communications Corp.                 instead of "foo" and "bar"
(706) 549-7689 | PGP KeyID=0xC72F3F1D   in Python examples. (Mark Lutz)