[DB-SIG] Remaining issues with DB API 2.0

[M.-A. Lemburg]

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 ?
> >
> > · 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.

Ok. Greg ?

> [...]
> 
> 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 :-) ? 

-- 
Marc-Andre Lemburg                               Y2000: 275 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------