[logback-dev] [JIRA] Created: (LBCLASSIC-188) Make table and column names overridable
Ceki Gulcu
ceki at qos.ch
Fri Feb 26 13:28:25 CET 2010
On 26.02.2010 12:46, Durchholz, Joachim wrote:
>> 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");
>> }
>
> How about
> enum TableName {EVENT, EVENT_PROPERTY, EVENT_EXCEPTION}
> public String getTableName(TableName tableName) {
> switch (tableName) {
> case EVENT: return "logging_event";
> case EVENT_PROPERTY: return "logging_event_property";
> case EVENT_EXCEPTION: return "logging_event_exception";
> }
> }
>
> Using an enum has two advantages:
> - Compilers can (some will) complain if you forget a case in the switch
> - uses of TableName can be traced with cross-referencing tools
>
> The disadvantage is that you can't extend the list.
> However, if that kind of flexibility is needed, I'm not sure that a
> separate resolver class is a good solution. It would need to provide a
> table name for whatever the internal workings of DBAppender require, so
> the coupling would be too tight.
> (If logback can use generic classes, then DBAppender<DBNameResolver>
> would be optimal IMHO.)
Using enums is a good idea. Both implementations of DBAppender the one
in logback-classic and the one in logback-access depend on distinct
table structures, but a table structure is assumed nonetheless. The
DBNameResolver only decouples the table/col names from that assumed
structure.
> Regards,
> Jo
More information about the logback-dev
mailing list