[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-169 at 2/26/10 11:39 AM: ---------------------------------------------------------------- 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. The same is probably true also for markers but at a lesser degree. 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. Reserving 8 columns for the arguments seems very reasonable.
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 them all together. Some special MDC values (node, slot, version, client, and reference) are stored into separate columns, the rest is stored into a map.
That's pretty smart. I think the scope of your proposal is quite different than Tomasz' original request. was (Author: noreply.ceki@qos.ch): 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. The same is probably true also for markers but at a lesser degree. 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. Reserving 8 columns for the arguments seems very reasonable.
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 them all together. Some special MDC values (node, slot, version, client, and reference) are stored into separate columns, the rest is stored into a map.
That's pretty smart. I think the scope of your proposal is quite different than Tomasz' original request. Note
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