[JIRA] Created: (LBCLASSIC-169) Customizing table names used by DbAppender
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: Logback dev list 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Greg Thomas commented on LBCLASSIC-169: --------------------------------------- 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
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: Logback dev list 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-169: -------------------------------------- Sounds pretty reasonable.
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
[ 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
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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Rü edited comment on LBCLASSIC-169 at 2/25/10 9:41 AM: ------------------------------------------------------- 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 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. Anyone interested?!? was (Author: rd): 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Rü edited comment on LBCLASSIC-169 at 2/25/10 9:43 AM: ------------------------------------------------------- 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 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. This is not in production use, yet, and I haven't measured the space and performance impact, but I think it could very well use just half the space on disk... which would mean several gigs per day in our environment. Anyone interested?!? was (Author: rd): 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 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. 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-169: -------------------------------------- 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
[ 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-169: -------------------------------------- Hello Tomasz, I saw your blog entry about logback-feed. I'll be sure to experiment with it asap. However, reading your comment dated "February 8, 2010 3:51 PM" to your own blog entry, it seems to me that you could create different feeds in at least 3 ways: 1A) change the feed source by writing to and reading from different database tables. DBAppender allows you to set the connection source, i.e. different tables. 1B) As I understand it, you would like to write to the same table with distinct DBAppenders writing to different columns of the same table. Logback-feeder would then read from different columns to create different feeds. 2) Let the user create different feeds by creating new logback-feed filtering rules, with logback-feed always reading read the same source (database table). To be honest, this second approach seems so much cleaner than 1A or 1B, unless of course I misunderstood you. Being able to override column or table names to comply with local convention is a different matter.
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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-169 at 2/26/10 12:04 PM: ---------------------------------------------------------------- Hello Tomasz, I saw your blog entry about logback-feed. I'll be sure to experiment with it asap. However, reading your comment dated "February 8, 2010 3:51 PM" to your own blog entry, it seems to me that you could create different feeds in at least 3 ways: 1A) change the feed source by writing to and reading from different database schemas. DBAppender allows you to set the connection source, enabling you to connect to a different schema per DBAppender. I have to admit that while possible creating a different schema to serve as a distinct feed source can be cumbersome (but possible). 1B) As I understand it, you would like to write to the same table with distinct DBAppenders writing to different columns of the same table. Logback-feeder would then read from different columns to create different feeds. If you have 3 different feeds you would have 3 times more columns in the event table which sound pretty messy to me. 2) Let the user create different feeds by creating new logback-feed filtering rules, with logback-feed always reading read the same source (database table). To be honest, this second approach seems so much cleaner than 1A or 1B, unless of course I misunderstood you. Being able to override column or table names to comply with local convention is a different matter. was (Author: noreply.ceki@qos.ch): Hello Tomasz, I saw your blog entry about logback-feed. I'll be sure to experiment with it asap. However, reading your comment dated "February 8, 2010 3:51 PM" to your own blog entry, it seems to me that you could create different feeds in at least 3 ways: 1A) change the feed source by writing to and reading from different database tables. DBAppender allows you to set the connection source, i.e. different tables. 1B) As I understand it, you would like to write to the same table with distinct DBAppenders writing to different columns of the same table. Logback-feeder would then read from different columns to create different feeds. 2) Let the user create different feeds by creating new logback-feed filtering rules, with logback-feed always reading read the same source (database table). To be honest, this second approach seems so much cleaner than 1A or 1B, unless of course I misunderstood you. Being able to override column or table names to comply with local convention is a different matter.
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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-169 at 2/26/10 12:22 PM: ---------------------------------------------------------------- Hello Tomasz, I saw your blog entry about logback-feed. I'll be sure to experiment with it asap. However, reading your comment dated "February 8, 2010 3:51 PM" to your own blog entry, it seems to me that you could create different feeds in at least 3 ways: 1A) change the feed source by writing to and reading from different database schemas. DBAppender allows you to set the connection source, enabling you to connect to a different schema per DBAppender. I have to admit that while possible creating a different schema to serve as a distinct feed source can be cumbersome (but possible). 1B) As I understand it, you would like to write to the same table with distinct DBAppenders writing to different columns of the same table. Logback-feeder would then read from different columns to create different feeds. If you have 3 different feeds you would have 3 times more columns in the event table which sound pretty messy to me. 2) Let the user create different feeds by creating new logback-feed filtering rules, with logback-feed always reading read the same source (database table). To be honest, this second approach seems so much cleaner than 1A or 1B, unless of course I misunderstood you. Being able to override column or table names to comply with local convention is a different matter. See also LBCLASSIC-188. was (Author: noreply.ceki@qos.ch): Hello Tomasz, I saw your blog entry about logback-feed. I'll be sure to experiment with it asap. However, reading your comment dated "February 8, 2010 3:51 PM" to your own blog entry, it seems to me that you could create different feeds in at least 3 ways: 1A) change the feed source by writing to and reading from different database schemas. DBAppender allows you to set the connection source, enabling you to connect to a different schema per DBAppender. I have to admit that while possible creating a different schema to serve as a distinct feed source can be cumbersome (but possible). 1B) As I understand it, you would like to write to the same table with distinct DBAppenders writing to different columns of the same table. Logback-feeder would then read from different columns to create different feeds. If you have 3 different feeds you would have 3 times more columns in the event table which sound pretty messy to me. 2) Let the user create different feeds by creating new logback-feed filtering rules, with logback-feed always reading read the same source (database table). To be honest, this second approach seems so much cleaner than 1A or 1B, unless of course I misunderstood you. Being able to override column or table names to comply with local convention is a different matter.
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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Rü commented on LBCLASSIC-169: ------------------------------ Ceki wrote:
I think the scope of your proposal is quite different than Tomasz' original request.
...moved to the sub-task.
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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-169: -------------------------------------- Normalization should go yet to a new subtask and this issue should be renamed as DBAppender redesign or similar.
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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu updated LBCLASSIC-169: --------------------------------- Summary: DBAppender redesign [was originally: Customizing table names used by DbAppender] (was: Customizing table names used by DbAppender)
DBAppender redesign [was originally: 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Tomasz Nurkiewicz commented on LBCLASSIC-169: --------------------------------------------- My idea was to have multiple DbAppenders, each writing to a completely separate set of logging tables, dedicated to each appender. The tables would have different names and each DbAppender would choose the target tables via logback.xml configuration file. Now table names are hard-coded, so even when creating multiple DbAppenders, they all use the same logging tables. Please assign me to LBCLASSIC-188, I can implement this feature.
DBAppender redesign [was originally: 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
[ http://jira.qos.ch/browse/LBCLASSIC-169?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-169: -------------------------------------- There is no need to have this assigned to you. Just do it. See also http://articles.qos.ch/contributing.html You are probably more interested in fixing LBCLASSIC-188. If you intend to override the way table names and columns are resolved, I strongly suggest adding a DBNameResolver as explained in LBCLASSIC-188.
DBAppender redesign [was originally: 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
participants (5)
-
Ceki Gulcu (JIRA) -
Greg Thomas (JIRA)
-
Maarten Bosteels -
Rü (JIRA)
-
Tomasz Nurkiewicz (JIRA)