develooper Front page | | Postings from January 2019

Re: RaiseWarn attribute for DBI

Thread Previous | Thread Next
January 21, 2019 15:55
Re: RaiseWarn attribute for DBI
Message ID:
On Sunday 20 January 2019 17:27:22 Tim Bunce wrote:
> On Fri, Jan 18, 2019 at 10:47:41AM +0100, wrote:
> > On Friday 18 January 2019 09:13:48 Tim Bunce wrote:
> > > On Thu, Jan 17, 2019 at 10:02:39AM +0100, wrote:
> > > > 
> > > > Currently DBI has only $dbh->{PrintWarn} attribute to control warnings.
> > > > When is set to true (by default) all warnings from DBI driver are passed
> > > > to perl's "warn" function.
> > > > 
> > > > So I would propose to add $dbh->{RaiseWarn} attribute (off by default)
> > > > to behave like $dbh->{RaiseError}, but for warnings.
> > > 
> > > I'd like to know more about the specific use-case(s) that prompted this.
> > 
> > Hi! The use-case is for testing code, that its SQL part does not produce
> > any warning. Lot of database server supports vendor specific SQL command
> > to convert warnings to errors, but there is no standard way how to do it
> > driver/database independent. And because DBI reports warnings via Perl's
> > warn, it is not possible to easily distinguish between DBI warnings,
> > internal Perl warnings and warnings generated by other 3rd modules.
> > 
> > So use-case is: raise DBI errors for any warning or error from database
> > server and let warnings reported by 3rd modules and by Perl itself as
> > is. So to ensure that database server does not produce any "problems".
> Couldn't HandleSetErr be used for this?
> Quoting the docs at
>     HandleSetErr, on the other hand, is called whenever set_err() is
>     called with a defined err value, even if false. So it's not just for
>     errors, despite the name, but also warn and info states. The set_err()
>     method, and thus HandleSetErr, may be called multiple times within a
>     method and is usually invoked from deep within driver code.
> Tim.

I'm looking at it and will try some tests...

Anyway, another use-case is for testing DBI SQL applications. If I write
tests for that application which should not produce any SQL warnings,
then with my approach RaiseWarn => 1 in DBI->connect I can simple ensure
that test fails if something unexpected happens.

With HandleSetErr it is maybe possible too, but needs non-trivial logic
for writing code ref subroutine and is not so simple and obvious for
people who read test code. With RaiseWarn => 1 I simple declare what
should happen when warning is generated; similarly like for already
existing RaiseError.

Reason why I chose RaiseWarn is because there is already PrintWarn,
PrintError and RaiseError attributes. So RaiseWarn just use same naming
and logic pattern.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About