[DB-SIG] Optional DB API Extensions

Federico Di Gregorio fog@debian.org
24 Oct 2001 15:50:10 +0200

Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2001-10-24 at 14:29, M.-A. Lemburg wrote:
> 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=20
> or to have them only be stored in the .messages lists=20
> 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)

agreed. and every module should provide 3 default handlers: one to log
to messages, one to raise an exception and one that sends all the crap
to /dev/null. how to switch between them? or we simply export them and
init the module with the .messages populating one?

Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
INIT.D Developer                                           fog@initd.org
  Those who do not study Lisp are doomed to reimplement it. Poorly.
                                     -- from Karl M. Hegbloom .signature

Content-Type: application/pgp-signature

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org