[ http://jira.qos.ch/browse/LBCLASSIC-187?page=com.atlassian.jira.plugin.syste... ] Rü commented on LBCLASSIC-187: ------------------------------ See the parent task for the start of a discussion about general nomalization. Ceki wrote:
How did you go about the normalization? Normalizing the level would not buy you anything as its just a field, a reference to the level form the event table to the level table would take just as much space.
I store the level name in addition to the level value, which can be useful for humans to read, but it's not really necessary, as Logback doesn't allow custom log levels... even not for LocationAwareLoggers.
The same is probably true also for markers but at a lesser degree.
Not when they have references to other markers!
Normalizing loggers is a different matter and would probably gain significant space. However, you would need to find out the id of each logger which would cost a database lookup, unless of course you start caching the logger references.
Of course I do ;-) Thinking of it, my caching of markers assumes that you don't add or remove references while running. Maybe markers should be unmodifiable (but that would require a slf4j API change).
Log request arguments should be placed in separate columns ----------------------------------------------------------
Key: LBCLASSIC-187 URL: http://jira.qos.ch/browse/LBCLASSIC-187 Project: logback-classic Issue Type: Sub-task Components: appender Affects Versions: 0.9.18 Reporter: Ceki Gulcu Assignee: Logback dev list
Originally reported by Greg Thomas: http://jira.qos.ch/browse/LBCLASSIC-169?focusedCommentId=11565#action_11565 I'm not so much interested in table/column names, but what I would like to see is the ability to record the individual values for the placeholders in the log message. If you're logging to a database, there's the possibility of running report on that database. Instead of having to parse out the data from the re-combined log message (e.g. "New call made; now 4 calls active"), it would be easier to record the value of arguments directly in the database. e.g. if you've configured it so that the first argument is stored in column arg1, and the second is stored in arg2, then the log entry logger.info( "New call made; now {} calls active", activeCallCount ); could appear in the database as (ignoring the other columns for this example) ... formatted_message: "New call made; now 4 calls active" arg1: "4" arg2: null
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira