logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: PreparedStatementAppender vs. JDBCAppenderPlus
Date Mon, 26 Apr 2004 21:30:57 GMT
Here are my comments:

1 - We should leave in support for configurable column names.  There are folks out there already
writing logging events to tables - and likely using this table or tables as a common logging
infrastructure in their enterprise across systems.  Allowing JDBCAppender to write events
to existing tables is a valid  use case.  If the goal is to provide a simple configuration,
maybe we could add a 'useDefaultColumnNames' param and support those columns in the appender
by default.

2 - Is there a reason we couldn't include both and get feedback from folks during the alpha
phase as to which they prefer, or maybe Danko and Ray could work together to combine the best
parts of both appenders into one?

I think it's great that we have two options and I'd like to get some 'real world' feedback
on their respective benefits before we decide to nix one or the other.

Scott


-----Original Message-----
From:	Ceki Gülcü [mailto:noreply@qos.ch]
Sent:	Mon 4/26/2004 2:02 PM
To:	log4j-dev@logging.apache.org
Cc:	
Subject:	PreparedStatementAppender vs. JDBCAppenderPlus

After studying both PreparedStatementAppender vs. JDBCAppenderPlus, I would 
like to build on mostly PreparedStatementAppender for the DBAppender to be 
included in the next version of log4j.

My preference goes to PreparedStatementAppender over JDBCAppenderPlus 
because of its simplicity although it maybe purportedly less flexible.

I think PreparedStatementAppender could be further simplified if we assumed 
fixed table columns. Is there any real advantage in allowing variation in 
the column names?  We don't allow any flexibility when using XMLLayout, why 
should we allow variation in the column names when writing to a DB? 
Flexibility without a real-world use case does not seem wise to me... Is 
there a use case where flexibility for the table columns would make sense?

By the way, when inserting events into the database, we can ensure that the 
primary key for each row is sequential. When reading from the database, a 
db receiver could insert the primary key into the properties under the key 
'pkey'. This should allow us to efficiently compare events coming from a db.
(I am assuming that an event will be inserted into a single table. Things 
get more complicated if one starts playing with one-to-many relationship 
between an event and its MDC and/or properties map.)


-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org





Mime
View raw message