cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <>
Subject Re: [jira] [Created] (CAY-1840) Conditionally log slow / long-running queries
Date Wed, 26 Jun 2013 15:55:06 GMT
On Wed, Jun 26, 2013 at 10:35 AM, Mike Kienenberger <>wrote:

> On Wed, Jun 26, 2013 at 10:40 AM, John Huss (JIRA) <>
> wrote:
> >              Summary: Conditionally log slow / long-running queries
> >                  URL:
> >
> > 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).
> +1 for moving sql logging down to debug level and leaving connection
> opening at INFO.
> > 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.
> +1 for using a different logger for slow queries, and maybe adjusting
> what is logged by default by logger level
> > 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.
> Don't we already log parameters with the existing logging code?

Yes, they are logged inside the SelectTranslator before the query is run.
 However, this new logging would happen AFTER the query has run and
currently there isn't public API to grab the query params from outside
SelectTranslator where this happens.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message