[DB-SIG] Remaining issues with DB API 2.0

Greg Stein gstein@lyra.org
Wed, 31 Mar 1999 17:44:31 -0800


M.-A. Lemburg wrote:
> 
> Andy Dustman wrote:
> >
> > 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 ?

Nope. IMO, there are already too many exceptions, and some of them are
rather unclear on how they are distinguished from one another.

> > >
> > >  Is there a strong need for "capability testing" other than using
> > >   hasattr() ?

Nope.

> >
> > 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.
> 
> Ok. Greg ?

I think it should be "optional void behavior, returning None". The lack
of a nextset() will probably not utterly break an application like lack
of a rollback. The thing here is that a nice behavior exists for nextset
when it isn't available: simply return None (which also happens to mean
"no more"). The semantics of its presence also match the semantics of
its absence.

I say leave the bugger in.

> 
> > [...]
> >
> > 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).
> 
> Would make a nice addendum to the spec... or maybe a separate
> document. Volunteers ? Andy :-) ?

IMO, very few applications need this portability. I'd definitely ask
that it be a second document, published in the db-sig area.

Review the apps that you have: how many were written to be truly
portable? Is your SQL portable? How about those column types? etc. I
know mine aren't, so I'm specifically anti-volunteering to do this :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/