Re^2: Can DBI modify queries on the fly?

[kyle]

I want to modify the queries of a running application so that what's passed to the database includes a comment that tells where in the Perl code the request originated. SQL::Library (or Data::Phrasebook) is a nice idea, but it solves a completely different problem.

Likewise, I don't want to step through my code in the debugger and modify queries by hand. Rather, this is a tedious task that I think the computer should do for me. More to the point, I can't sit at the debugger in production.

[doom]

I want to modify the queries of a running application so that what's passed to the database includes a comment that tells where in the Perl code the request originated.

Well, there is such a thing as an SQL comment, and for at least some databases (e.g. MySQL), I believe the comments get logged along with the SQL. (There was one occasion where I solved a problem like this with screwed-up capitalization, e.g. changing "SELECT" to "SeLECT", "SElECT", "SELeCT"...).

Have you looked at the "TRACING" features listed in the DBI docs? That at least can be turned on dynamically, though if the docs are up-to-date, I infer that it doesn't have SQL logging yet:

       Curently the DBI only defines two trace flags:

         ALL - turn on all DBI and driver flags (not recommended)
         SQL - trace SQL statements executed (not yet implemented)

Update: actually, I bet that turning on trace level 1 is pretty close to what you're asking for. It will echo your prepare statements (including the SQL), and label them with line number and file of your code:

  $dbh->trace(1, $trace_log_file);

[jfroebe]

Understood. I would advise strongly against doing this in production though. Most DBMSs will have a performance penalty for writing to the errorlog (or any external file). But... it's your code/server.

[kyle]

We're not planning to write everything to a log, but there's a "slow queries" log for when something takes too long, and I'd like those entries to have a little more information in them. Unfortunately, I can't always tell ahead of time which queries those will be, so I need to add my special bonus info to everything.

[jfroebe]

Instead of writing to the DBMS errorlog, how about writing to a table? It would probably have a smaller performance impact. It would also allow you to determine which queries are most often used.. allowing you to focus your energy on the worst.

Which DBMS are you using? There might be tools that would identify the slow queries that you could use in conjunction with your code line => query.