: I think you're confusing the hierarchy of your database's types with the : hierarchy in Java. In Java, a java.sql.Blob and a java.sql.Clob are 2 : different things. They do not extend a common ancestor (excpt
Exactly - regardless of what the informix docs may say about how column types are related (for the purposes of casting an conversion in SQL) what matters is how the JDBC driver you are using maps your databases types to java types, some quick googling pulls up this result... http://docs.oracle.com/cd/E17904_01/web.1111/e13753/informix.htm#i1065747 Which lists specifically.. Informix BLOB -> JDBC BLOB Informix CLOB -> JDBC CLOB Informix TEXT -> JDBC LONGVARCHAR ...i suspect that there is not any real problem with the ClobTransformer -- it seems to be working perfectly, dealing with the CLOB fields returned appropriately -- but there may in fact be a problem with if/how DIH deals with JDBC values that are LONGVARCHARs. Since i don't see Types.LONGVARCHAR mentioned anywhere in the DIH code base, i suspect it's falling back to some default behavior assuming String data which doesn't account for the way LONGVARCHAR data is probably returned as an Object that needs to be streamed similar to a Clob. specifically, some quick googling for LONGVARCHAR in the JDBC APIs suggests that ResultSet.getUnicodeStream or ResultSet.getCharacterStream should be used for LONGVARCHAR columns -- but i don't see any usage of that method in the DIH code base. geeky2: would you mind opening a bug to fix support for LONGVARCHAR in JdbcDataSource? -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
