Uploaded DBIx::Log4perl to CPAN



I've uploaded DBIx::Log4perl 0.04 to CPAN.

DBIx::Log4perl uses Log4perl to log to a file, send email, even
log to DBI itself (see Log::Log4perl::Appenders) details
about what SQL you've prepared, parameters passed to execute or
execute_array, result-sets, transactions etc etc without the
overhead of turning DBI tracing on.

The main advantages of DBIx::Log::Log4perl are:

o you can incorporate various classes of errors in your code and change what gets logged without changing your code.

o Log::Log4perl contains a highly configurable configuration with
lots of different appenders (targets for the messages) and a class-like
organisation of logging.

o you can direct debug, info, error, warnings, fatal etc to different
Log4perl appenders which means for instance debug info can go to a file
(when debug is enabled) and fatals to an email etc.

o it is not as verbose as DBI tracing

o it concentrates on the external side of DBI rather than the
internals of DBI i.e. you get to see the SQL you've prepared and
the parameters you've passed in execute etc but not all of the other
internal DBI stuff.

o it includes a DBI error handler which attempts to output
everything it can possibly find out about an error raised by
DBI (some features of this need the latest DBI and two features
of this require a yet-to-be-released DBI).

FYI: I'm rather impressed with Log::Log4perl and I'd recommend it
to anyone wanting to get different classes of debugging and error
logging out of their module.

I'm not making any great claims for it (I hope) but it has helped me
locate and identify a number of bugs and optimisations in
the perl DBI code I'm working on and I thought it may help
others.

I don't think DBIx::Log4perl is indexed on CPAN yet but it is under
the MJEVANS author tree.

Martin
.



Relevant Pages

  • Re: DBI v2 - The Plan and How You Can Help
    ... I can see room for all of them, but all of this is really a DBD, not a DBI, issue. ... and some of them have to resort to search-n-replace in the SQL string at execute() time since the database doesn't have native support. ... ie, on Pg the STHs would be built before the DB is connected, and on Oracle they are built the first time they are used. ... well I am thinking of large program environments here where data dictionaries and generated SQL are the norm. ...
    (perl.dbi.users)
  • request for clarification, was (DBD::DB2 execute and finish problem)
    ... DBI documentation says execute on a an active statement should imply a finish ...
    (perl.dbi.users)
  • Re: Memory access problem with DBI or DBD-Mysql?
    ... It seems that the problems are only with the "do" method and not with the "execute", so I looked for the differences between them. ... I want to repeat that the problem manifest itself only under OpenBSD because of it's memory management that cause the program to segfault if try to access a non allocated memory. ... I'm using DBI 1.45 and DBD-Mysql 2.9008. ...
    (perl.dbi.users)
  • Re: DBI v2 - The Plan and How You Can Help
    ... Darren Duncan wrote: ... of them, but all of this is really a DBD, not a DBI, issue. ... > DBD to decide whether to actually do anything with it immediately or not. ... a database) in your BEGIN block, and execute thousands of times after that. ...
    (perl.dbi.users)
  • Re: Tracing SQL queries done via DBI (mod_perl)
    ... There is a tracemethod on DBI, however, it does not properly print ... dbd_st_prepare calling count_params ... <- execute= 1 at dbitest.pl line 10 ... <- DESTROY= undef during global destruction ...
    (comp.lang.perl.misc)