Die sQLshell wurde in einer neuen Version veröffentlicht. Grund dafür war eine Inkompatibilität des Oracle-JDBC-Treibers

JDBC war eine gute Idee von Sun. Leider zeigen sich in der Praxis einige Unzulänglichkeiten - besonders wenn man eine Anwendung schreibt, die portabel zwischen vielen Datenbanksystemen sein und dabei noch über bloßes Abfragen von Daten hinausgehen soll.

Mein absoluter Spitzenreiter in dieser Beziehung ist Informix: vor mehreren Jahren wurde die sQLshell im Umfeld einer Anwendung eingesetzt, die Informix zum Persistieren der Daten benutzte. Ständig bekam ich neue Tickets über Fehlverhalten der sQLshell. Ich kann heute nicht mehr genau sagen, wann das Fass überlief, aber irgendwann war ich so kaputtgespielt, dass ich selbst einen JDBC-Treiber für Informix schrieb, der eine Fassade vor den eigentlichen Treiber setzte und alle Unzulänglichkeiten wegbügelte. Mein Erweckungserlebnis in diesem Zusammenhang war die Tatsache, dass man per JDBC fragen kann, ob eine spezielle Art von Cursor bzw. ResultSet unterstützt wird. Tat man das bei Informix und fragte nach einem Scrollable Resultset, nickte Informix heftig mit dem Kopf. Wollte man ein solches anschließend auch wirklich vom Treiber haben, antwortete der mit einer SQLException "Type of ResultSet not supported...

Heute jedoch hat Oracle aufgeholt. Man kann aus den Metadaten eines ResultSet auf zwei verschiedene Arten auf die Typen der enthaltenen Daten rückschließen: zum einen kann man nach dem SQL-Typ fragen. Als Antwort erhält man einen Integer, der als symbolische Konstante in java.sql.Types definiert ist. Als zweite Möglichkeit kann man nach der Java-Klasse fragen, die die Daten der jeweiligen Spalte repräsentiert - die Methode getObject liefert dann eine Instanz dieser Klasse. Zitat aus der API: "Returns the fully-qualified name of the Java class whose instances are manufactured if the method ResultSet.getObject is called to retrieve a value from the column." Will man also mit diesen Informationen etwas anfangen, muss man mittels java.lang.Class.forName das Ergebnis in ein tatsächliches Klassen-Objekt umwandeln.

Das war der Punkt, wo Oracle kreativ wird - wenn es sich bei der Spalte um eine vom Typ CLOB handelt: Alle anderen Treiber liefern als Klassennamen welche aus den Standard-Packages zurück - also beispielsweise java.sql.Timestamp, java.math.BigDecimal oder java.lang.String. Oracle tut das auch - nur eben nicht bei CLOBs - dort kommt com.oracle.OracleClob zurück. Dieser Name ist dann auch prompt - wegen der Eigenarten des ClassLoader-Mechanismus im Zusammenhang mit JDBC - nicht per java.lang.Class.forName auflösbar, was in einer Exception endet und im Falle der sQLshell die Wirkung hatte, dass man mit der Anwendung keine CLOB-Spalten in Oracle-Datenbanken bearbeiten konnte. Postgres und HSQL bilden CLOB auf String ab und Cloudscape liefert als Klassenname korrekt java.sql.Clob zurück.

Daher also der Patch für die sQLshell die damit die Ermittlung der Spalteneigenschaften um einen weiteren Sonderfall erweitert wurde.