> > 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.
I think we should be working off the 3.0 spec at this point. It is intended to be backwards compatible and thus an acceptable reference for log4j. > >> 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. I will read up on this in the next day or so. > >> 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? the addBatch(String sql) command will take any sql statement (including the current layout-based creations) and place them all into a batch for execution. This could (and should) be done within the flushBuffer() method of the JDBCAppender. Use of addBatch would of course be contingent on the DatabaseMetaData indicating support for it. This would take a small update to the current code. Would end of the week be early enough for this improvement? For other things: I can put forward an example of my two-tier idea sometime in June. I could include a Retriever implementation at that time as well if log4j developers want to go that direction. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
