[DB-SIG] Re: How to handle database warnings ?
Anthony Tuininga
Anthony@COMPUTRONIX.com
Mon, 23 Jul 2001 08:42:06 -0600
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C11385.A550AB30
Content-Type: text/plain;
charset="iso-8859-1"
Is there any reason why the Python warning framework would not be used?
Other than that it is not available until Python 2.1? The advantage to this
method is that it makes use of an existing framework and the users of the
module would have more control of which warnings they care to see and which
ones they would rather not see; otherwise, the module designer dictates what
are warnings and what are exceptions or a new framework (as is being
discussed) would need to be developed.
Anthony Tuininga
-----Original Message-----
From: John Shafaee [mailto:pshafaee@hostway.net]
Sent: Monday, July 23, 2001 8:20 AM
To: M.-A. Lemburg
Cc: db-sig@python.org
Subject: Re: [DB-SIG] Re: How to handle database warnings ?
I am personally in favor of clearing the list after each call to execute().
This
allows the programmer ample opportunity to make note of the list contents if
so
desired. The semantics of clearing after a call to execute() is also more
clear
and intuitive. You can optionally add an extra method that can be used to
flush
the error/warning queue on demand.
"M.-A. Lemburg" wrote:
> John Shafaee wrote:
> >
> > I agree with your approach. I wrote my own DB factory class and DB
interface
> > wrapper which simply grabs the DB warning exceptions and ignores them
(well,
> > it makes note of them silently). THis has worked very well for me and
has
> > passed the test of time.
> >
> > It would be great to have this support at a lower level as it will make
> > working with stored procedures a lot easier, as you have already noted.
>
> Right, that's the idea. I am only curious about when to clear the
> list of messages/warnings. Currently, I think that clearing the list
> prior to all method calls would be a good idea, but I'm not sure
> whether this would perhaps be to radical... perhaps the list should
> contain all messages (errors + warnings) which occurred the last
> .execute() ?!
>
> This would make testing for warnings somewhat more difficult though.
>
> > John S
> >
> > db-sig-request@python.org wrote:
> >
> > > Send DB-SIG mailing list submissions to
> > > db-sig@python.org
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > http://mail.python.org/mailman/listinfo/db-sig
> > > or, via email, send a message with subject or body 'help' to
> > > db-sig-request@python.org
> > >
> > > You can reach the person managing the list at
> > > db-sig-admin@python.org
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of DB-SIG digest..."
> > >
> > >
------------------------------------------------------------------------
> > > Today's Topics:
> > >
> > > 1. How to handle database warnings ? (M.-A. Lemburg)
> > >
> > >
------------------------------------------------------------------------
> > >
> > > Subject: [DB-SIG] How to handle database warnings ?
> > > Date: Fri, 20 Jul 2001 20:07:24 +0200
> > > From: "M.-A. Lemburg" <mal@lemburg.com>
> > > Organization: eGenix.com Software GmbH -- http://www.egenix.com/
> > > To: "DB-SIG @ Python.org" <db-sig@python.org>
> > >
> > > I am currently working on a modification to mxODBC which solves
> > > the problems users sometimes have with database warnings.
> > > Since I think that some other database modules may have the
> > > same problem, I would like to get your opinion about this.
> > >
> > > mxODBC currently converts most warnings from the database
> > > into Python exceptions. This sometimes causes failure of
> > > more complex operations like e.g. calling stored procedures.
> > >
> > > To solve this, I've added a list attribute .messages to both
> > > connection and cursor objects which will hold the error
> > > and warning messages generated by the low-level code in the
> > > order they are generated by the database. Errors will still be
> > > reported using Python exceptions, but I am planning
> > > to drop the exception mechanism for warnings.
> > >
> > > The latter will then only be available by looking at the
> > > .messages list.
> > >
> > > Now to make this easy and also to avoid the generation of
> > > large message lists, I am thinking of auto-clearing the
> > > .messages lists after prior to all method calls.
> > >
> > > This would then enable code like:
> > >
> > > c.execute(sql)
> > > if c.messages:
> > > # got some warnings
> > > print c.messages
> > > for row in c.fetchall():
> > > ...
> > >
> > > What do you think ?
> > >
> > > --
> > > Marc-Andre Lemburg
> > > CEO eGenix.com Software GmbH
> > > ______________________________________________________________________
> > > Company & Consulting: http://www.egenix.com/
> > > Python Software: http://www.lemburg.com/python/
> >
> > _______________________________________________
> > DB-SIG maillist - DB-SIG@python.org
> > http://mail.python.org/mailman/listinfo/db-sig
>
> --
> Marc-Andre Lemburg
> CEO eGenix.com Software GmbH
> ______________________________________________________________________
> Consulting & Company: http://www.egenix.com/
> Python Software: http://www.lemburg.com/python/
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
------_=_NextPart_001_01C11385.A550AB30
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [DB-SIG] Re: How to handle database warnings ?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Is there any reason why the Python warning framework =
would not be used? Other than that it is not available until Python =
2.1? The advantage to this method is that it makes use of an existing =
framework and the users of the module would have more control of which =
warnings they care to see and which ones they would rather not see; =
otherwise, the module designer dictates what are warnings and what are =
exceptions or a new framework (as is being discussed) would need to be =
developed.</FONT></P>
<P><FONT SIZE=3D2>Anthony Tuininga</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: John Shafaee [<A =
HREF=3D"mailto:pshafaee@hostway.net">mailto:pshafaee@hostway.net</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 23, 2001 8:20 AM</FONT>
<BR><FONT SIZE=3D2>To: M.-A. Lemburg</FONT>
<BR><FONT SIZE=3D2>Cc: db-sig@python.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [DB-SIG] Re: How to handle database =
warnings ?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>I am personally in favor of clearing the list after =
each call to execute(). This</FONT>
<BR><FONT SIZE=3D2>allows the programmer ample opportunity to make note =
of the list contents if so</FONT>
<BR><FONT SIZE=3D2>desired. The semantics of clearing after a call to =
execute() is also more clear</FONT>
<BR><FONT SIZE=3D2>and intuitive. You can optionally add an extra =
method that can be used to flush</FONT>
<BR><FONT SIZE=3D2>the error/warning queue on demand.</FONT>
</P>
<P><FONT SIZE=3D2>"M.-A. Lemburg" wrote:</FONT>
</P>
<P><FONT SIZE=3D2>> John Shafaee wrote:</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > I agree with your approach. I wrote my own =
DB factory class and DB interface</FONT>
<BR><FONT SIZE=3D2>> > wrapper which simply grabs the DB warning =
exceptions and ignores them (well,</FONT>
<BR><FONT SIZE=3D2>> > it makes note of them silently). THis has =
worked very well for me and has</FONT>
<BR><FONT SIZE=3D2>> > passed the test of time.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > It would be great to have this support at =
a lower level as it will make</FONT>
<BR><FONT SIZE=3D2>> > working with stored procedures a lot =
easier, as you have already noted.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>> Right, that's the idea. I am only curious about =
when to clear the</FONT>
<BR><FONT SIZE=3D2>> list of messages/warnings. Currently, I think =
that clearing the list</FONT>
<BR><FONT SIZE=3D2>> prior to all method calls would be a good idea, =
but I'm not sure</FONT>
<BR><FONT SIZE=3D2>> whether this would perhaps be to radical... =
perhaps the list should</FONT>
<BR><FONT SIZE=3D2>> contain all messages (errors + warnings) which =
occurred the last</FONT>
<BR><FONT SIZE=3D2>> .execute() ?!</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>> This would make testing for warnings somewhat =
more difficult though.</FONT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>> > John S</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > db-sig-request@python.org wrote:</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > > Send DB-SIG mailing list submissions =
to</FONT>
<BR><FONT SIZE=3D2>> > =
> =
db-sig@python.org</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > To subscribe or unsubscribe via the =
World Wide Web, visit</FONT>
<BR><FONT SIZE=3D2>> > =
> <A =
HREF=3D"http://mail.python.org/mailman/listinfo/db-sig" =
TARGET=3D"_blank">http://mail.python.org/mailman/listinfo/db-sig</A></FO=
NT>
<BR><FONT SIZE=3D2>> > > or, via email, send a message with =
subject or body 'help' to</FONT>
<BR><FONT SIZE=3D2>> > =
> =
db-sig-request@python.org</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > You can reach the person managing the =
list at</FONT>
<BR><FONT SIZE=3D2>> > =
> =
db-sig-admin@python.org</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > When replying, please edit your =
Subject line so it is more specific</FONT>
<BR><FONT SIZE=3D2>> > > than "Re: Contents of DB-SIG =
digest..."</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > =
------------------------------------------------------------------------=
</FONT>
<BR><FONT SIZE=3D2>> > > Today's Topics:</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > 1. How to handle =
database warnings ? (M.-A. Lemburg)</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > =
------------------------------------------------------------------------=
</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Subject: [DB-SIG] How to handle =
database warnings ?</FONT>
<BR><FONT SIZE=3D2>> > > Date: Fri, 20 Jul 2001 20:07:24 =
+0200</FONT>
<BR><FONT SIZE=3D2>> > > From: "M.-A. Lemburg" =
<mal@lemburg.com></FONT>
<BR><FONT SIZE=3D2>> > > Organization: eGenix.com Software =
GmbH -- <A HREF=3D"http://www.egenix.com/" =
TARGET=3D"_blank">http://www.egenix.com/</A></FONT>
<BR><FONT SIZE=3D2>> > > To: "DB-SIG @ Python.org" =
<db-sig@python.org></FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > I am currently working on a =
modification to mxODBC which solves</FONT>
<BR><FONT SIZE=3D2>> > > the problems users sometimes have =
with database warnings.</FONT>
<BR><FONT SIZE=3D2>> > > Since I think that some other =
database modules may have the</FONT>
<BR><FONT SIZE=3D2>> > > same problem, I would like to get =
your opinion about this.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > mxODBC currently converts most =
warnings from the database</FONT>
<BR><FONT SIZE=3D2>> > > into Python exceptions. This =
sometimes causes failure of</FONT>
<BR><FONT SIZE=3D2>> > > more complex operations like e.g. =
calling stored procedures.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > To solve this, I've added a list =
attribute .messages to both</FONT>
<BR><FONT SIZE=3D2>> > > connection and cursor objects which =
will hold the error</FONT>
<BR><FONT SIZE=3D2>> > > and warning messages generated by the =
low-level code in the</FONT>
<BR><FONT SIZE=3D2>> > > order they are generated by the =
database. Errors will still be</FONT>
<BR><FONT SIZE=3D2>> > > reported using Python exceptions, but =
I am planning</FONT>
<BR><FONT SIZE=3D2>> > > to drop the exception mechanism for =
warnings.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > The latter will then only be =
available by looking at the</FONT>
<BR><FONT SIZE=3D2>> > > .messages list.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > Now to make this easy and also to =
avoid the generation of</FONT>
<BR><FONT SIZE=3D2>> > > large message lists, I am thinking of =
auto-clearing the</FONT>
<BR><FONT SIZE=3D2>> > > .messages lists after prior to all =
method calls.</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > This would then enable code =
like:</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > c.execute(sql)</FONT=
>
<BR><FONT SIZE=3D2>> > > if =
c.messages:</FONT>
<BR><FONT SIZE=3D2>> > > # =
got some warnings</FONT>
<BR><FONT SIZE=3D2>> > > =
print c.messages</FONT>
<BR><FONT SIZE=3D2>> > > for row in =
c.fetchall():</FONT>
<BR><FONT SIZE=3D2>> > > =
...</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > What do you think ?</FONT>
<BR><FONT SIZE=3D2>> > ></FONT>
<BR><FONT SIZE=3D2>> > > --</FONT>
<BR><FONT SIZE=3D2>> > > Marc-Andre Lemburg</FONT>
<BR><FONT SIZE=3D2>> > > CEO eGenix.com Software GmbH</FONT>
<BR><FONT SIZE=3D2>> > > =
______________________________________________________________________</=
FONT>
<BR><FONT SIZE=3D2>> > > Company & =
Consulting: &=
nbsp; &=
nbsp; <A HREF=3D"http://www.egenix.com/" =
TARGET=3D"_blank">http://www.egenix.com/</A></FONT>
<BR><FONT SIZE=3D2>> > > Python =
Software: &nb=
sp; &nb=
sp; <A HREF=3D"http://www.lemburg.com/python/" =
TARGET=3D"_blank">http://www.lemburg.com/python/</A></FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>> > DB-SIG maillist - =
DB-SIG@python.org</FONT>
<BR><FONT SIZE=3D2>> > <A =
HREF=3D"http://mail.python.org/mailman/listinfo/db-sig" =
TARGET=3D"_blank">http://mail.python.org/mailman/listinfo/db-sig</A></FO=
NT>
<BR><FONT SIZE=3D2>></FONT>
<BR><FONT SIZE=3D2>> --</FONT>
<BR><FONT SIZE=3D2>> Marc-Andre Lemburg</FONT>
<BR><FONT SIZE=3D2>> CEO eGenix.com Software GmbH</FONT>
<BR><FONT SIZE=3D2>> =
______________________________________________________________________</=
FONT>
<BR><FONT SIZE=3D2>> Consulting & =
Company: &nbs=
p; &nbs=
p; <A HREF=3D"http://www.egenix.com/" =
TARGET=3D"_blank">http://www.egenix.com/</A></FONT>
<BR><FONT SIZE=3D2>> Python =
Software: &nb=
sp; &nb=
sp; <A HREF=3D"http://www.lemburg.com/python/" =
TARGET=3D"_blank">http://www.lemburg.com/python/</A></FONT>
</P>
<BR>
<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>DB-SIG maillist - =
DB-SIG@python.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mail.python.org/mailman/listinfo/db-sig" =
TARGET=3D"_blank">http://mail.python.org/mailman/listinfo/db-sig</A></FO=
NT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C11385.A550AB30--