At 12:26 22.05.2002 -0700, Kevin Steppe wrote: >Ceki et al., > >First, my apologies for being terse in my message, I'm just short on time >this month.
Sure. >Problems: > addBatch is an optional method in Statement. It is not guarenteed to > be implemented by all drivers (in fact it is not implemented in the mySQL > driver I use). > Your logEvents table definition is not valid on all databases. And in > fact it's not valid on -most- databases. And any table we come up with > will lack something a user may want, until we have some much that it's > overly bloated for 95% of the users. Then we would likely need to write > several different versions of the table creation to support the different > databases. addBatch is an optional method? Version 2.0 of the JDBC spec. clearly mentions Batch statements in Chapter 6. Can you please point me to the where in the JDBC spec. Batch Statements are declared as optional? Yes, table creation syntax admits variation between the different DNMS vendors. However, table creation is not under the responsibility of JDBCAppender. First, what any log4j appender does is tp utput an o.a.log4j.spi.LoggingEvent object to some output device. A JDBCAppender does the same. It outputs a LoggingEvent to a DBMS. Second the number of databases in the world is limited. If we could reliably write to say DB2, MySQL, Oracle, PostgreSQL (note the alphabetical order) we'd be in good shape. Third, although there are variations in the SQL syntax, the bulk of the work of the JDBCAppender consists of sending an INSERT statement to the database. And as far as I know, in most databases, in particualr as DB2, MySql, PostgreSQL (could not check Oracle yet), the syntax of the INSERT command is INSERT INTO tablename (col1, col2, ...) VALUES (val1, val2, ...) Looks simple enough to me. Unless someone does it first, I'll write an appender that can reliably insert complete logging events to a table on MySQL and PostgresQL. When that is done, I am sure someone else will continue on DB2, Oracle and what have you. > Note that your prepared statements were in fact slower than simple > statements and not all databases truely support prepared statements > (mySQL is the only slacker that I know of but there may be others). The difference is minimal and the winner changes between runs. Sometimes simple statements are win and sometimes prepared statements do, although batch statements are always way ahead. >Suggestions/Solutions/Previous design considerations: > > When I first wrote the JDBCAppender I knew that it would be used on a > variety of databases in different circumstances for users with different > logging needs. The base level JDBCAppender needs to support that level > of generality. The only way to support that variety is to leave the sql > and the table definition to the user. The current JDBCAppender supports > this in an easy and straight forward way. In particular, if users want > prepared statements they can set the sql to call a stored procedure of > their choice (in essence what the prepared statement does). The > advantage here is that the users' table can be matched to their > particular needs -- for example, storing Thread but not NDC, or Class & > line number, or an Event extension... It also allows them to log to an > existing table in a legacy installation. > Due to the problems above and the design goals in the previous > paragraph I am strong opposed to tieing the basic JDBCAppender to a > particular table definition. There are obviously advantages to being totally flexible. On the other hand, total flexibility by the way of delegation to the user does not give you any foundation to build upon. As for the argument about optional NDC, class/line number/method name fields, we can expect the table to contain *all* fields but choose not to insert the information if that is what the user desires. This is similar to what is done with SocketAppender where location info is optional but the LoggingEvent contains the field, even when it is null. -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
