On Friday 24 May 2002 23:37, Kevin Steppe wrote:
> Niclas Hedhman wrote:
> > SQL is by default an evil thing and should not be exposed to users, nor
> > programmers.
>
> That is rather opinionated, just like the following:
> SQL is by default an incredibly elegant, simple, and powerful
> programming language -- in some ways more elegant and powerful than
> Java. All programmers would benefit from learning SQL.
When I say "evil" I mean "current specification is not strict enough and
allows for the implementation vendors to extend it in all kinds of
incompatible directions", hence making "pluggability" a paper-tiger.
> > I suggest that the SQL is completely hidden from Log4J, so that each
> > JDBC-using appender has a method, or a client class, that takes care of
> > the retrieval of the exact same information as what can be stored, plus
> > some basic search methods (not SQL based) and optionally(!) have an
> > exposure of SQL statement executions.
>
> Under the current design appenders in log4j only store LoggingEvents not
> retrieve them, so it would be rather odd for the JDBCAppender to have
> search methods. Log reading is delegated to Chainsaw/user/etc. In fact
> the log formats are primarily the domain of the Layout classes, not the
> appenders. I believe that this was a very wise design choice. I
> suspect it's useful for appenders to expose information about their
> output formating/etc for the benefit of a reader, but I'll let Chainsaw
> folks take authority on that one.
Badly formulated on my part.
The MySQLAppender, should be accompanied by a MySQLRetriever, that is
pluggable into Chainsaw and other viewers. This is not violating the Log4J
design philosophy, because the SocketAppenders has the corresponding classes
"for the other end", which in your argument should not be the case.
> The programmer writes: log.debug("a debug message") [no SQL]
> The deployment person puts in the config: sql=insert into logTable
> (logMessage) values ('%m') [only enough to pick the right output]
> This supports all DBs, and the SQL is completely hidden from log4j and
> it's user.
If the deployer is allowed to send the log record into any database in any
format, you yell "Bravo", and I whisper "too bad". I will bet that most
deployers only require that he/she specifies the Host+port+DB and the name of
the Table (plus user/pass of course).
However, I am arguing that a rather fixed format is established, or ChainSaw
and others will never manage to pick up the info, and you would discourage
small 3rd party tools to analyze the data.
So, to re-phrase;
Instead of talking about JDBC appenders, let met introduce the concept of
Retrievers, which are implemented as a companion to Appenders.
The rationale is that exactly the same is true for non-JDBC appenders, such as
for XML and even text files.
If the Retriever interface is established, then it is up to the Appender
writer to provide, or risking that people won't use it due to inaccessability
of the output.
As for JDBCAppender, I think it will evolve a little bit, so that the
Retriever interface would/can be supported, and free format Insert statements
are probably not reasonable.
My highly opinionated assertion is most humble, of course.
Niclas
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
