logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicko Cadell <ni...@neoworks.com>
Subject RE: Persisting LoggingEvents across languages
Date Wed, 28 Apr 2004 17:30:41 GMT
The log4net ADONetAppender does not define the database layout. Currently
the user is required to design their own table structure and then define a
stored procedure or prepared statement to write into the database. A layout
is used to render each parameter to the stored procedure or prepared
Using a stored procedure would allow the user to store the MDC & property
values in separate tables, however this would be a complex stored procedure.

Example configurations are here:

The appender allows specific MDC or Properties values to be extracted into
custom columns, or combined together to make up a single column.

Are you proposing that the DBAppender would only work with a fixed database

I suppose that you have already thought about how this should work, so you
may have thought/discounted/done any of the following:

Rather than having a separate join table for MDC and Properties (and any
other key/value fields) you can combine these into a single table with a
context column:

CREATE TABLE [dbo].[LogEventValues] (
	[EventId] [int] NOT NULL,
	[Context] [int] NOT NULL,
	[Key] [varchar] (255) NOT NULL,
	[Value] [varchar] (4000) NULL

Where EventId is a foreign key into the LogEvent table, Context looks up
into a table with values for MDC and Properties. I think that the MDC is
actually "Thread Context" and Properties is actually "Event Context".
This means that if we want to add another context, for example properties
tied to a specific LoggerRepository or global properties, a database schema
change is not required.

The records of a stack trace need to be ordered and therefore have a 'key'
which is used for sorting. Therefore it would also be possible to use the
same table above to store the stack trace records for the event, the Context
would lookup to stack trace, the Key would be an alpha string to sort on
e.g. A, B, C etc... and the value would be the info for the stack frame.

Having a fixed database schema will allow tools to be written to interrogate
the logged events. Currently I use the SQL Query Analyser to inspect the
logs, but others may prefer a dedicated GUI tool.

There may be scope for having two appenders or at least being able to
configure the appender to either write to the 'standard' table layout or to
use a user specified table.
The user will have to be able to configure the names of the tables to write
into and probably also the names of the columns. Different users have
different requirements for the naming of database tables and columns.

One completely different alternative is to write the event into the database
as XML (XmlLayout). Many databases have a native XML data type and can
perform xpath style queries on the contents of the field. XML would allow
different log4x platforms (or other user programmes) to add additional
fields to the data using namespaces to demark the values.


> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch] 
> Sent: 28 April 2004 13:32
> To: general@logging.apache.org
> Subject: Persisting LoggingEvents across languages
> Hi all,
> For log4j 1.3, I would like DBAppender, i.e. the successor to 
> JDBCAppender, to be able to persist to a database in a format 
> independent of the Java language.
> For most fields this is not a problem except for the MDC (a 
> map), properties (a map) and exceptions (an array of type string).
> I am thinking of persisting each of these multi-valued fields 
> into their own table. Thus, there will be a table for 
> LoggingEvents containing most fields except for the 
> throwable, MDC and properties.
> The MDC field will be stored in its own table, consisting of 
> a foreign key to the owning LoggingEvent instance, a column 
> for the key and a column for the value. Each row in the MDC 
> table will correspond to one (value,key) pair in an MDC 
> instance. The throwable would also be stored in its own 
> table, with each row corresponding to a line in the stack 
> trace. The properties map will be stored in the same way as the MDC.
> The advantage over java object serialization is that none of 
> the fields would be opaque for the database and also 
> programming language independent. 
> Thus, one would be able to perform SQL queries on the MDC or 
> the properties. (Give me all the events for userid=john).
> Do log4cxx, log4net, or log4pgp support persistence of 
> logging events into a db? Should we work on this in a 
> coordinated fashion?
> --
> Ceki Gülcü
>       For log4j documentation consider "The complete log4j manual"
>       ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  

View raw message