Re: DBI and placeholders, see resulting query?

Replies are listed 'Best First'.
Re^2: DBI and placeholders, see resulting query? by Anonymous Monk on May 21, 2014 at 13:22 UTC
Clearly they are asking how it's done, you tell them that you do it, not how to do it.	[reply]
Re^3: DBI and placeholders, see resulting query? by mr_mischief (Monsignor) on May 21, 2014 at 14:22 UTC
Actually, no. Printing the query with the placeholders and then another line with the parameters supplied is not the same as outputting the final query as if it had not been parameterized. The point is that it's simpler to output those two pieces of information together and gets the author within a very short distance of the stated goal.	[reply]
Re^4: DBI and placeholders, see resulting query? by Anonymous Monk on May 21, 2014 at 14:29 UTC
So, easier than turning on tracing in one place and having it spew the real query out? Right.	[reply]
Re^5: DBI and placeholders, see resulting query? by mr_mischief (Monsignor) on May 21, 2014 at 16:43 UTC
Re^2: DBI and placeholders, see resulting query? by locked_user sundialsvc4 (Abbot) on May 21, 2014 at 15:04 UTC
Sigh ... Reckon it’s fairly easy to see how to do that, say with the `join()` function, or maybe with Data::Dumper. There are lots of ways to implement my suggestion, if one cares to do so, and I don’t think that every single suggestion has to be accompanied by extemporaneously-written Perl source code. I’m just not as good at that, as other people are! Often, my own logging-messages are more app-specific anyhow. I don’t necessarily need to see the actual SQL-string; what I really need to know are the parameters (and these in application terms) that were sent in to it. I already know, from the validation test-suite, that the query is correctly written and that it produces the intended results. (Of course, of course ... Mmmmm...??) So what I really want to know most is what are the values that are being given at that particular point. A dump – even literally a Data::Dumper dump – of the input parameters to a function might actually be the most useful, because I already know from validation-tests that the function itself works. One more thought: be certain that these types of results appear only in log-files, never in anything that might be sent back to a web-browser. Yes, you can exploit a web-site by causing it to fail and then “stuffing” the debugging-messages that were meant only to be seen by the developer.