[logback-dev] [JIRA] Commented: (LBCLASSIC-188) Make table and column names overridable
Ceki Gulcu (JIRA)
noreply-jira at qos.ch
Tue Mar 23 23:03:16 CET 2010
[ http://jira.qos.ch/browse/LBCLASSIC-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11674#action_11674 ]
Ceki Gulcu commented on LBCLASSIC-188:
--------------------------------------
> I am not actually convinced to your version of DBNameResolver. You can
> now pass virtually any enum to the resolver (for instance
> java.util.concurrent.TimeUnit) instead of table or column name
> enum. Also the interface seems very complicated with "<E extends
> Enum<?>>" construct. Maybe I don't get the idea right?
I think that since the enums are passed to the resolver from within
logback, the risk of using the wrong enum type is very low.
> Second thing is putting all column names in a single enum. It has the
> advantage that adding new tables to DbAppender won't have such a big
> impact on code (no new classes or methods). But when number of columns
> increase, single enum containing all columns in all tables would very
> likely to grow enormously. Also, each value in this enum should have
> table name prefix to avoid conflicts, which is very awkward.
The number of columns and tables cannot increase freely. The table
structure is likely to change very slowly if at all. Even if the same
column name is used in different tables, collisions are not an
issue. If column name 'A' exists both in table X and table Y, the
column name 'A' is correct for both tables (by definion), i.e.
collisions are not a problem.
> Also I find the ability to change particular column names directly
> from logback.xml being very important - that's why some many setters
> in my version of CustomDbNameAppender. Of course typically
> table/column, prefix/suffix customization is only needed, so I added
> SimpleDBNameResolver as suggested. I believe that majority of users
> would like to change single table/column name - and changing this via
> logback.xml is much easier and straightforward rather than
> implementing some logback-specific interface (please note that this
> tieds the application with Logback API).
Adding support for map like components in joran would resolve this
question for good. However, I already mentioned a possible naming
strategy based on prefix/suffixes without requiring enhancements to
Joran.
> Make table and column names overridable
> ---------------------------------------
>
> Key: LBCLASSIC-188
> URL: http://jira.qos.ch/browse/LBCLASSIC-188
> Project: logback-classic
> Issue Type: Sub-task
> Components: appender
> Affects Versions: 0.9.18
> Reporter: Ceki Gulcu
> Assignee: Logback dev list
>
> To comply with local project rules, it can be helpful if the table and column names used by DBAppender could be overridden. The easiest way to solve this problem is for DBAppender to delegate the resolution of table names and columns to a different class, say DBNameResolver. Here is a possible interface:
> interface DBNameResolver {
> String getTableName(String standardTableName);
> String getColumnName(String standardColumnName);
> }
> The default implementation of DBNameResolver could be:
> class DefaulDBNameResolver implements DBNameResolver {
> public String getTableName(String standardTableName) {
> if("logging_event".equals(standardTableName) {
> return standardTableName;
> }
> if("logging_event_property".equals(standardTableName) {
> return standardTableName;
> }
> if("logging_event_exception".equals(standardTableName) {
> return standardTableName;
> }
> throw new IllegalArgumentException(standardTableName + " is an unknown table name");
> }
> String getColumnName(String standardColumnName) {
> ...
> }
> }
> If a user wanted to use different names she would simply implement DBNameResolver according to her requirements.
> Any volunteers to implement this?
--
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
More information about the logback-dev
mailing list