The current version looks great to me. I may (or may not) tweak a few minor things after you commit, but it is fine the way it is.
Andrus On Jul 22, 2013, at 4:23 PM, John Huss <johnth...@gmail.com> wrote: > Andrus, can you take a look at the updated patch? Thanks. > > On Monday, July 8, 2013, John Huss (JIRA) wrote: > >> >> [ >> https://issues.apache.org/jira/browse/CAY-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] >> >> John Huss updated CAY-1840: >> --------------------------- >> >> Attachment: >> 0001-CAY-1840-Conditionally-log-slow-long-running-queries.patch >> >> Ok, updated patch for review. >> >>> Conditionally log slow / long-running queries >>> --------------------------------------------- >>> >>> Key: CAY-1840 >>> URL: https://issues.apache.org/jira/browse/CAY-1840 >>> Project: Cayenne >>> Issue Type: Improvement >>> Components: Core Library >>> Affects Versions: 3.2M1 >>> Reporter: John Huss >>> Assignee: John Huss >>> Priority: Minor >>> Attachments: >> 0001-CAY-1840-Conditionally-log-slow-long-running-queries.patch >>> >>> >>> I wanted to add logging slow / long-running queries without having to >> log every single query, so I made a patch to do it. But there are a lot of >> implementation questions and some general design questions about the >> jdbcLogger. >>> 1) I added a property to control the logging threshold - seems like >> these should go in Constants, but there was already a property defined in >> JdbcAdapter where I was working, so I just put it there. Also, I'm not >> sure what the property naming conventions are exactly. I called it >> "cayenne.server.query_execution_time_logging_threshold" >>> 2) For the JdbcLogger, currently all the messages are at the INFO level. >> I can't add this new logging with that level because then you wouldn't be >> able to see just the long-running queries, you would still see all or none. >> So I added generic "warn" method that uses the WARN level. But I wonder >> if a more semantic method would be better, like "logLongQuery" or >> something. Also, I wonder if it would be better to push the existing SQL >> logging down to the debug level and leave the connection opening at the >> INFO level so you could just see those logs (which is something I have >> wanted). >>> 3) I am logging only the SQL string and not the parameters because there >> wasn't any easy way to access the params from the logger. Ideally the >> params would be logged also. >>> 4) In Project Wonder some functionality like this exists, but it allows >> you to pair log levels with query running times, so you could log at the >> WARN level for queries longer than one second and log at the ERROR level >> for queries longer than five seconds. I don't think this is very important >> as it complicates the property API, but I thought I would throw out the >> idea. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >>
