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
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
