cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <>
Subject [jira] [Closed] (CAY-1840) Conditionally log slow / long-running queries
Date Tue, 23 Jul 2013 14:16:51 GMT


Andrus Adamchik closed CAY-1840.

       Resolution: Fixed
    Fix Version/s: 3.2M2
> Conditionally log slow / long-running queries
> ---------------------------------------------
>                 Key: CAY-1840
>                 URL:
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 3.2M1
>            Reporter: John Huss
>            Assignee: John Huss
>            Priority: Minor
>             Fix For: 3.2M2
>         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:

View raw message