Anyone interested?!?
yes, I am interested. I think having the most common MDC keys like sessionId, requestId, remoteIP (well the list will be different for every app) in the same table as the event itself will drastically improve the throughput of the appender (one insert instead of 4). It's on my TODO list, and it could be interesting to have a look at your solution. regards, Maarten On Thu, Feb 25, 2010 at 9:42 AM, Rü (JIRA) <noreply-jira@qos.ch> wrote:
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste...]
Rü commented on LBCLASSIC-169: ------------------------------
I actually have written a new database appender normalizing all the entities that are quite static: Level, Logger, and Marker.
I've put the message and the arguments into separate columns, although that is not 100% clean, as I can now only store up to a fixed number of arguments (8 right now), which I currently consider a reasonable compromise.
I additionally normalized a session entity wich consists of the Thread name and the MDC... these don't change for a lot of log messages and it's nicer to have the together. Some special MDC values (node, slot, version, client, and reference) are stored into separate columns, the rest is stored into a map.
Anyone interested?!?
Customizing table names used by DbAppender ------------------------------------------
Key: LBCLASSIC-169 URL: http://jira.qos.ch/browse/LBCLASSIC-169 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.18 Reporter: Tomasz Nurkiewicz Assignee: Ceki Gulcu Priority: Minor
ch.qos.logback.classic.db.DBAppender uses hard-coded table names for logging events: logging_event, logging_event_property and logging_event_exception. Allowing to change these default names has two benefits: * There are systems where database table names must follow some naming conventions (prefixes, using underscores vs. camel case) * One could create several Db appenders, each operating on different set of tables (for performance reasons or more fine grained logging and filtering) Each table name would be configured using a property in logback.xml. Default values for table names would be the same as present ones to maintain backward compatibility. If you are interested in this feature let me know, I can implement it and provide a patch.
-- 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 logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev