[ http://jira.qos.ch/browse/LBCLASSIC-199?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-199. ---------------------------------- Resolution: Won't Fix Just not worth the trouble given that it is not hard to reconstitute the throwable by selecting from the logging_event_exception table by event_id and iterating through the results.
better structure for logging_event_exception table in DBAppender ----------------------------------------------------------------
Key: LBCLASSIC-199 URL: http://jira.qos.ch/browse/LBCLASSIC-199 Project: logback-classic Issue Type: Sub-task Components: appender Reporter: Ceki Gulcu Assignee: Ceki Gulcu
Placing each stack trace line in a new row in string form (without explicit columns for the class, file and line number) is a little silly. Instead of aggregating the stack trace into a single line, a separate column for the various exception fields would have been better because it would allow searches based on exception classes/messages or stack traces. IMO, the nicest approach table structure would be akin to: CREATE TABLE logging_event_exception ( event_id INT NOT NULL, i SMALLINT NOT NULL, -- 0 for the topmost exception, incremented by one for each nested exception exception_class VARCHAR(256) NOT NULL, exception_msg VARCHAR(1024), stack_trace VARCHAR(16384) PRIMARY KEY(event_id, i), FOREIGN KEY (event_id) REFERENCES logging_event(event_id)); where i would be incremented by one for each 'root cause'. If in addition, the LOGGING_EVENT table contained the total number of nested exception, it would be rather easy to retrieve the original exception plus its root causes.
-- 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