[ http://jira.qos.ch/browse/LBCLASSIC-188?page=com.atlassian.jira.plugin.syste... ] 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