Hi Michael, > first of all thanks for your response. I think I forgot to tell this, > as I'm usuallyworking from Monday to Wednesday or Thursday only, > it may take some time till I respond to the mails here.
As you might have noticed, my answers are delayed, too - I do not work on Fridays, and sometimes not on Thursdays (parental part time, or however this is called in English). > Now towards the weird driver architecture. You are right, my driver > does not inherit from the MySQL driver, it's rather inspired by the > MySQL driver and wraps around the driver I inherit from the JDBC driver. > The wrapping is to provide some SDBCX services in addition to the SDBC > services of the driver I inherit from the JDBC driver, pretty similar to > the MySQL driver providing SDBCX services in addition to the SDBC > services of JDBC driver. Okay, this part is slightly ugly, but hard too improve without reasonable effort. > The inheritance from the JDBC driver is mainly > to overwrite the isAutoIncrement() Method of the XResultSetMetaData > interface which the JDBC driver implements. Now this part is *really* ugly :) The JDBC driver can change in its ABI at any time without notice, since it's considered an internal component. When you have a driver which links against the JDBC driver and is not part of the core source tree, this driver will sooner or later become non-functional. Also, even if your driver where part of the core source, I would have headaches with exporting all its classes and implementation structure "just" to override such a single facet. Is there a possibility to add some kind of "compatibility switch" to your DB's JDBC driver? That is, your wrapping driver could add some parameter (like "report-sequences-as-auto-increment=true" or whatever fancy name you can imagine) to the connection URL, and your JDBC driver would use this to control the behavior of isAutoIncrement. If this doesn't work, I would vote for introducing a generic mechanism in OOo's JDBC bridge (let me call it "bridge" instead of "driver", since it effectively bridges from JDBC to SDBC, and to not confuse it with a "real" JDBC driver) for manipulating the result set meta data, and then employ this mechanism from your wrapping driver. As an example, consider the type info returned by the DatabaseMetaData. The JDBC bridge (and in particular the ODatabaseMetaDataBase class in connectivity/source/commontools/TDatabaseMetaDataBase.cxx) supports a setting "TypeInfoSettings" (passed in the PropertyValue sequence upon connecting), which is used to effectively transform the type information as retrieved from the database. So, if we have a database/setup which needs to fake the type information, this (to a certain extent) can be done by simply creating a proper TypeInfoSettings value. Something similar could perhaps be done for the result set meta data. If we have a setting which captures the "when the default value of a column is 'sequence_name.nextval', then return 'true' in isAutoIncrement" rule, then your wrapping driver could pass this setting to the JDBC driver. I suppose the RowFunctionParser in connectivity/source/*/RowFunctionParser.* already does almost or all of what is needed to create such a rule. Then only the ResultSetMetaData implementation of the JDBC bridge needs to accept and respect such a setting. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
