JDBC getTableName cast von ResultSetMetaData zu PGResultSetMetaData

Hallo,

habe da ein kniffliges Problem mit JDBC:

ResultSetMetaData rsmd = result.getMetaData();
String tableName = rsmd.getTableName(1);

liefert immer “” (leerer String) zurück, was am Treiber liegt. Der Workaround soll sein, dass mittels eines cast von ResultSetMetaData zu PGResultSetMetaData die Methode getBaseTableName auf zu rufen. MAche ich das via:

tableName = ((org.postgresql.PGResultSetMetaData)rsmd).getBaseTableName(1);

erhalte ich

java.lang.ClassCastException: org.postgresql.jdbc3.Jdbc3ResultSetMetaData cannot be cast to org.postgresql.PGResultSetMetaData

zurück. Hat das schon jemand mit postgresql-8.2-509.jdbc3.jar hin bekommen?

Danke & Grüsse,

marc.

PGResultSetMetaData ist nur fuer ResultSetMetaData in Typ-2 und Typ-4 Treibern verfügbar

(Das habe ich “herausgefunnden” indem ich mir mal die Klassenhierachie dieses Interfaces angeschaut habe - und da tauchen nur JDBC2 und JDBC4 Klassen auf … ich habe hier aber auch einen neueren Treiber als du verwendest - den 8.3.)

Du arbeitest offensichtlich mit einem Typ-3 Treiber …

… frag mich nicht warum Typ 3 fehlt

Besten Dank für die schnelle Antwort! Werde das gleich mal ausprobieren!

Liebe Grüsse,

marc.

Sorry, aber das wars nicht.

Mit einem kleinen Testprogramm und postgresql-8.2-509.jdbc3.jar funktioniert der cast PGResultSetMetaData pgrsmd = (PGResultSetMetaData)rs.getMetaData(); - nur in Tomcat via JNDI Resource/Conection Pool geht das nicht. Seit dem ich nicht mehr via JNDI verbinde, sondern selber eine Connection aufbaue, klappt es tadellos - auch mit postgresql-8.2-509.jdbc3.jar.

Liebe Grüsse,

marc

ich habe die treiber-version nur als referenz genannt

der jdbc-typ hat damit nichts zu tun … der sagt nur, auf welche weise der treiber mit dem backend kommuniziert … typ-1 z.B. ueber die odbc bridge und typ-4 direkt … dazwischen gibt es noch typ-2 und typ-3 …

diese duerften sowohl fuer den 8.2 als auch den 8.3 treiber implementiert sein (nicht jeder jdbc treiber muss alle typen supporten)

was du nun feststellst ist, das unterschiedliche verhalten des treibers -je nach art des verbindungsaufbau - was darauf hindeutet, dass im Fall A eben ein anderer Typ angewendet wird als in Fall B.

also da wo es funktioniert -> direkte verbindung … da wo es nicht funktioniert -> indirekt (jndi -> middleware -> typ-3) weil das eben keine Typ-4 verbdingung ist …

zum schlau-machen:
Java Database Connectivity – Wikipedia

also die art des verbindungsaufbaus legt den verwendeten jdbc-typ fest - das macht der jdbc-treiber dann … wie es scheint ist dieses PGResultSetMetadata Interface nicht fuer Typ-3 implementiert (siehst du an der Klassenhierachie) … warum das so ist kann ich dir nicht sagen … möglicherweise wurde es vergessen - oder es ist schlichtweg nicht möglich diese informationen ueber Typ-3 verbindungen zu liefern.

Besten Dank für die Klärung - dann liegt es also am Protokoll…

Derzeit bekommst Du auch von den großen DB Herrstellern wie ORACLE
nur noch Class 4 Teiber empfohlen, da die anderen Teilweise native
JINI Verbindungen aufweisen können und da kann es ja immer mal
zu unerwünschten Seiteneffekten kommen.

Class 4 Treiber sind auf jeden Fall 100% pure Java und wickeln
alles von innerhalb der JVM ab und sind zu 99% auch die Treiber
die wenig Stress und maximale Performance liefern und auch mit
den gängigen ConnectionPoolern wie z.B Apache DBCP oder
dem SUN GlassFish AppServer keinen Ärger machen.

aber … in infrastrukturen die ueber den horizont der DMZ hinauslaufen u.U. einfach nicht eingsetzt werden können

aber …
aber …
aber …
aber …
aber …

Tendenziell halte ich Dich zwar für nen Spinner, aber diesmal könntest Du recht haben.