Niclas Hedhman wrote:
> Sorry, but I don't buy this argument.
> 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.
Now that doesn't mean that all programmers -should- learn SQL or need to
in order to log into a database (see below for a continuation of this).
Heck, I would benefit from learning compiler theory, which doesn't mean
I'm going to do it.
>
> The others suggestion that a prefixed table format would improve the chances
> of additional tools is extremely valid.
>
> 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.
>
> Then it is a matter of creating variants for different databases, possibly
> including a very generic one that can easily be extended by the project
> programmers. The "user", very often i.e deployment people, tech support
> people and so forth, has to know what DB they want to store to, pick up the
> appropriate DB Appender, and go,go,go...
Exactly. And this is the current state of affairs.
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.
>
> By having a proper client API to such appenders, it is possible to not only
> write user interfaces, but often, more importantly, allow JUnit testing to be
> more thorough in its response evaluation.
>
> Along the same line, JDO is such a powerful SQL abstractor, which I don't
> recommend to be part of the main distribution, but perhaps Log4J is getting
> to the point where such additional support is in separate JARs (like Ant) for
> people who wants/needs it. JDO structures has the additional advantage that
> the DB structure is, claimed to be, multi-language supported. Meaning a OMG
> Data Object Model compliant implementation in a non-Java language can be
> processing the output. (Haven't seen that yet, but the Java side of things is
> very good from a persistence point of view, albeit implementation specific.)
I've heard good things about JDO, which is the extent of my knowledge
about it. I'd be happy to be enlightened.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
