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