At 08:14 24.05.2002 -0700, Kevin Steppe wrote: >>>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? > >JDBC2.1 spec (I couldn't find 2.0 on the sun site): >"6.2 What's Required > >Support for batch updates is optional. If a JDBC driver supports batch >updates, the the DatabaseMetaData.supportsBatchUpdates() method must >return true, else it must return false. In addition, to preserve backward >compatibility, JDBC drivers that do not continue processing after a >failure are not required to return a value of -2 as described in Section >6.1, however, this is encouraged. JDBC drivers that continue processing >are required to support both of the negative return values. > >Note: In the future, the JDBC API shall define symbolic constatns for the >negative array entry values described in Section 6.1. These values have >been added as an addendum to the original JDBC2.0 API specification." > >Also note JDBC 3.0 final release Chapter 6: "Any features not identified >here [add Batch is not listed] are optional. In general, a driver is not >required to implement any feature that its underlying data source does not >support." > >And of course the JavaDoc (where I first found the optional note): >http://java.sun.com/j2se/1.4/docs/api/java/sql/Statement.html#addBatch(java.lang.String)
Thank you very much. You can find the JDBC 2.0 spec at http://java.sun.com/products/jdk/1.2/docs/guide/jdbc/index.html Note that there is no section 6.2 in this version of the spec. >Now fortunately the DatabaseMetaData will tell us whether it is supported >or not and we can cover both cases intelligently. Right. >>Yes, table creation syntax admits variation between the different DNMS >>vendors. However, table creation is not under the responsibility of >>JDBCAppender. > >However, if we confine the JDBCAppender to a single pre-determined >definition, then it is our/log4j's responsibility to provide that syntax. We could state the requirements on the database structure without creating it. This is somewhat similar to the JDBC Realm in Tomcat. See http://jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-howto.html for more details. >>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. > >I would add MS-SQL Server and Sybase to that list. Still, as you point >out, a fairly managable number, all with reasonable adherence to SQL92. Yes, MS-SQL and Sybase are equally important platforms. >>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. > >I suspect Ceki won't like this suggestion, but I'll make it anyway: If I don't like it is probably because I am too thick headed to understand it. :-) >Have a two-layer solution. First a totally flexible JDBCAppender, such as >the current implementation, for the sql savvy user. Second, build a >defined-table implementation on top of that -- as a subclass or >whatever. This way the savvy user gets some core functionality, the basic >user gets a well verified implementation, and other components have a >table definition they can write to. How is the current implementation of the JDBCAppender (based on patterns) compatible with batch statements? Am I missing something here? -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
