martin-evans.me.uk Always finish the day on a success

Whilst at YAPC::EU 2012 (what a great conference BTW) a friend suggested I might change DBIx::Log4perl to DBIx::LogAny (where Log::Any did not exist when I wrote DBIx::Log4perl). DBIx::Log4perl came about when I was writing a large DBI based application and needed to know what was going on and realized the DBI tracing was far too detailed for us. DBIx::Log4perl logs at different levels DBI method calls and in particular everything it can find when an error occurs. Mostly all I needed was everything I could find when an error occurred but logging SQL passed to do and prepare and bound parameters etc was useful too.

Personally, we use DBIx::Log4perl here at $work and using Log::Any makes little sense to us. However, I saw the point and thought it might be a fairly simple task with some benefit for others.

It wasn't that difficult except:

o DBIx::Log4perl uses caller_depth to change the place where Log::Log4perl reports the tracing was issued. Log::Any does not have any way to change this. The Log::Any author suggested I could continue to do this but what if Log::Log4perl was not being used. Eventually I found Module::Loaded and made all the caller_depth changes dependent on whether Log::Log4perl was loaded.

o Log::Log4perl supports passing a closure to the log functions such that it is not evaluated until Log::Log4perl ascertains that it is logging at that level. DBIx::Log4perl makes extensive use of that and Log::Any does not support it. Here again, after talking with the Log::Any author it was troublesome for him to add support for this and he suggested just removing the sub {xxx} in log calls and testing the log level. I didn't really want to do this but had no option in this case and it does not really make a lot of difference (it may even be a little faster).

I'll try to keep DBIx::Log4perl and DBIx::LogAny in synch for as long as I can but I may eventually drop DBIx::Log4perl.