And sorry about the delay. With the release out of the door, I have more time available to the actual Cayenne work :)
On Jul 22, 2013, at 4:27 PM, Andrus Adamchik <[email protected]> wrote: > I will, thanks! > > On Jul 22, 2013, at 4:23 PM, John Huss <[email protected]> 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 >>> > >
