[DB-SIG] Optional DB API Extensions

[M.-A. Lemburg]

"Dittmar, Daniel" wrote:
> 
> Would it be useful to have a common connection option 'strict'?
> 
> Setting this option would generate warnings for optional features, even if
> the driver supports them. Thus hopefully hinting at portability problems.
> This option would also be used for certain implementation defined behaviour
> (e.g. BLOB columns could return a string object as the strict/portable
> behaviour and some kind of stream as the extended/nonportable behaviour).

-1. 

ODBC has gone down that road and the result is a complete mess of
mixing APIs levels with behaviour changes etc. pp.

I think the better way to handle extensions is having the user
explicitly request them, e.g. for the BLOB extension you mention the
module could require the user to set a special type converter
prior to executing a .fetch() operation.

However, 'strict' reminds me of the way error handling is done
in codecs and I think that this idea would also nicely apply
to the DB API spec (only that this time we should use callables
instead of strings).

The reasoning here is that I believe it should be possible
to request e.g. that all Warnings be raised as excpetions 
or to have them only be stored in the .messages lists 
or to completely silence them.

This could be done by adding an optional writeable errorhandler
attribute to connections and cursors. The handler is then
called like so :

	handler(connection_or_cursor, errorclass, errorvalue)

It could then either raise the exception, log it in .messages
or ignore the error (e.g. for informational Warnings).

How's that ?

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/