No worries!
On Mon, Jul 22, 2013 at 8:28 AM, Andrus Adamchik <[email protected]>wrote: > 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 > >>> > > > > > >
