[
http://jira.qos.ch/browse/LBCLASSIC-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11579#action_11579
]
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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
