If the column names can't be configured and the user wants to configure them, isn't make a view to map the column and names always an option? To me it appears that the user can "configure" the column names in the Database instead of log4j. Please correct me if I am wrong.
James Stauffer
-----Original Message-----
From: Danko Mannhaupt [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 27, 2004 8:35 AM
To: Log4J Developers List
Subject: Re: PreparedStatementAppender vs. JDBCAppenderPlus
I agree, that PreparedStatementAppender is simpler and could be used as a base for the future DBAppender. It should be possible to extend it to include additional features, such as MDC support.
I think that most users create their own custom logging table with custom columns and types. It is sometimes even required to write custom log objects, not just Strings, to the database. Consequently, IMHO the appender should offer flexibility and extensibility, at least to provide custom column names.
Danko
----- Original Message -----
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 27, 2004 11:29 AM
Subject: RE: PreparedStatementAppender vs. JDBCAppenderPlus
>
>
> 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. <snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
