On May 8, 2013, at 12:40 PM, Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Nick, > > On 5/8/13 1:34 PM, Nick Williams wrote: >> >> On May 8, 2013, at 12:08 PM, Michael-O wrote: >> >>> Am 2013-05-08 14:38, schrieb Christopher Schultz: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> Nick, >>>> >>>> On 5/8/13 8:08 AM, Nick Williams wrote: >>>>> >>>>> On May 8, 2013, at 6:54 AM, Christopher Schultz wrote: >>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> Michael, >>>>>> >>>>>> On 5/8/13 3:01 AM, Michael-O wrote: >>>>>>> I recently have started using the SlowQueryReport to >>>>>>> tackle performance issues. The log message, >>>>>>> unfortunately, does not contain the parameters passed to >>>>>>> the prepared statements. Though AbstractQueryReport >>>>>>> receives this information in >>>>>>> >>>>>>> protected String report*Query(String query, Object[] >>>>>>> args, final String name, long start, long delta) >>>>>>> >>>>>>> but ignores this information. The report would highly >>>>>>> benefit from. E.g., Commons DBUtils prints out the query >>>>>>> and the parameters in the case of an exception. The sole >>>>>>> query isn't really helpful. >>>>>>> >>>>>>> Can we add this? >>>>>> >>>>>> Sure. >>>>>> >>>>>>> Should I file a ticket? >>>>>> >>>>>> Yes. A BZ issue with a patch is likely to get done a whole >>>>>> lot faster than one without a patch (plus you get credit >>>>>> for your contribution). >>>>>> >>>>>> - -chris >>>>> >>>>> There needs to be an option to disable logging query >>>>> parameters somehow. Query parameters are sometimes sensitive, >>>>> and in some environments (medical, legal, etc.) logging them >>>>> might even be in violation of the law. >>>> >>>> +1 >>>> >>>> If you really want to get cute, allow the user to specify named >>>> query parameters that should never be displayed "e.g. >>>> 'password'", though this is a) perhaps not possible and b) not >>>> reliable because you can bind parameters by position as well as >>>> by name. >>> >>> Java has no support for named parameters. How is that supposed to >>> work? >> >> Agreed that it the setting won't be effective if they don't use >> prepared statements. Therefore, the setting name should reflect >> this restriction. >> >> I'm not sure what Chris is referring to. You are right, Java has no >> support for named parameters, even in Java 8. Chris might be >> thinking of Hibernate or Spring's JdbcTemplate, which permit using >> named parameters. Ultimately, these get converted to indexed >> parameters before the query is actually executed. > > I'm talking about java.sql.ResultSet.updateFoo(String columnName, Foo > fooData) > > Or are all your queries SELECTs?
Interesting. My (possible incorrect) understanding of ResultSet.updateFoo is that it does not execute a SQL statement. The database server has the cursored log held in memory and a direct binary message is sent back to update that column on that record. Therefore, there is no SQL statement to be logged by the SlowQueryReport. My (again, possibly incorrect) understanding of the SlowQueryReport is that it only applies to Statements, PreparedStatements, and CallableStatements. These only have indexed parameters.
smime.p7s
Description: S/MIME cryptographic signature
