Hello Mel, The DB schema is modeled after ILoggingEvent and it so happens that the timestamp field is a long representing the value returned by System.currentMillis(). With DBAppender which is comparatively slow, the cost of converting timestamp (milliseconds since 1970-01-01) to a proper date would be acceptable. However, when reading back from the database you would need a data structure other than or extending ILoggingEvent to make use of the additional date column, which is certainly feasible. I encourage you to play around with the enhancement you have in mind and file a bug report including your changes in the form of a patch. If you wait a little you might even be able to use github. Cheers, Mel T wrote:
We need to write our own DBAppender. I want us to have it very similar to the logback DBAppender (i.e. use the same DB schema plus our own fields).
I wonder why this appender defines the date columns as big int. Are these some of the reasons ?
- native dates are hard to support accross multiple DBs
- timezone and DST can really hurt us.
- it is faster to write a big int than a date where a clendar would have to be passed into the ps.setTimestamp calls.
or are there other reasons?
Mel T.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch