logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: PreparedStatementAppender vs. JDBCAppenderPlus
Date Tue, 27 Apr 2004 09:29:15 GMT

Complex things are fine as long as there is a justifying use case. However, 
for a package with the size of log4j, unnecessary complexity can be our 
worst enemy.

At 11:30 PM 4/26/2004, Scott Deboy wrote:
>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.

I think that the table where DBAppender writes to should be sharable across 
languages. It makes so much easier to support a simple and common base. If 
someone insists on naming their event columns according to "enterprise" 
standards, then they can continue to do so. It is none of our business. The 
goal of DBAppender is to offer a robust, simple and easy to use platform 
for placing logging events. The vast majority of users do not even care how 
the columns are named as long as they can easily write to them and read 
from them using a receiver.

>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 totally agree that we should discuss and debate use cases for variable 
columns.

>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.

I totally agree. We have the exceptional luxury of choosing between two 
good solutions.

>Scott

No one has commented on the idea of using sequential ids to distinguish 
between logging events.

 > 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