develooper Front page | perl.dbi.dev | Postings from January 2019

Re: Better diagnostic support in DBI

Thread Previous
From:
pali
Date:
January 29, 2019 12:12
Subject:
Re: Better diagnostic support in DBI
Message ID:
20190129121210.nigbxbupdr2sd4zk@pali
On Thursday 24 January 2019 13:57:23 Daniƫl van Eeden wrote:
> I think this would be very useful.
> 
> Another thing you could consider is a hash where the error/warning number is
> the key and an list of msgs is the value.

I think this is just complicated to create create and use. Is there any
real benefit to have such hash?

> But your proposed solution is probably simpler to consume.

Yes, for DBI applications it should be easier to consume.

> On 24 January 2019 10:44:58 pali@cpan.org wrote:
> 
> > On Wednesday 23 January 2019 20:19:27 Tim Bunce wrote:
> > > A key goal of the DBI is to provide a database independant interface to
> > > databases to enable application portability.  What you're suggesting
> > > seems inherently database specific.
> > 
> > As wrote DBI already has API for providing last error/warning/note and I
> > just tried to extend this API to provide list, not just one value. So
> > tried to describe some API which returns list.
> > 
> > Do you think that providing list of errors/warnings/notes is database
> > specific?
> > 
> > For example MySQL and MariaDB databases may produce more then one
> > warning for last executed statement. Same apply for PostgreSQL and
> > in databases with some kind of PL/SQL you can in most cases raise
> > warnings / errors too.
> > 
> > For example, here is simple PostgreSQL statement which cause generation
> > of more warnings and info messages:
> > 
> >  \set VERBOSITY verbose
> >  SET client_min_messages TO DEBUG;
> > 
> >  DO $$ BEGIN RAISE NOTICE 'my notice' USING ERRCODE = '00001'; RAISE
> > WARNING  'my warning' USING ERRCODE = '00002'; RAISE INFO 'my info'
> > USING ERRCODE =  '00003'; RAISE DEBUG 'my debug' USING ERRCODE =
> > '00004'; RAISE WARNING 'my  warning' USING ERRCODE = '00005'; END $$;
> > 
> >  NOTICE:  00001: my notice
> >  WARNING:  00002: my warning
> >  INFO:  00003: my info
> >  DEBUG:  00004: my debug
> >  WARNING:  00005: my warning
> > 
> > And SQL statement for MariaDB which cause 2 warnings:
> > 
> >  \W
> > 
> >  SELECT CAST("1a" AS INT), CAST("2b" AS INT);
> > 
> >  Warning (Code 1292): Truncated incorrect INTEGER value: '1a'
> >  Warning (Code 1292): Truncated incorrect INTEGER value: '2b'
> > 
> > Both examples does not produce any error, just warnings or info
> > messages.
> > 
> > I guess that similar thing -- more then one warning for one statement --
> > can happen also in other databases.
> > 
> > > The DBI defines a way for drivers to offer database specific functionality.
> > > 
> > > A good way to move a suggestion like this move forward is to work with
> > > multiple driver authors to add similar functionality to their drivers.
> > 
> > Therefore I'm writing to this list :-) What other developers think...
> > 
> > > Exposing the full features that a specific database makes available, via a
> > > database specific interface, is immediately helpful for users of that driver.
> > > 
> > > Once multiple drivers provide similar functionality then it would be
> > > reasonable to work on a design for extending the DBI itself.
> > > 
> > > Tim.

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About