[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