16.8 ResultSet und RowSet *
Ein ResultSet haben wir als Lieferanten von Zeileninformationen kennengelernt. Mit einem Cursor konnten wir über Zeilen laufen und auch scrollen, wenn positionierbare Cursor angemeldet waren. Updates waren ebenfalls möglich. Ein ResultSet ist allerdings kein Datencontainer, vergleichbar mit einer Liste, die alle Daten bei sich hat. Das ResultSet muss immer eine Verbindung mit der Datenbank haben, und ein Aufruf von next() könnte sich die Zeileninformationen immer von der Datenbank besorgen. Ein ResultSet ist also kein Container, der Daten speichert. Aus diesem Grund implementiert ResultSet auch nicht die Schnittstelle Serializable.
16.8.1 Die Schnittstelle RowSet
Mittlerweile gibt es die Schnittstelle javax.sql.RowSet, die von interessanten Klassen implementiert wird. Ein RowSet ist ein ResultSet – das heißt, die Schnittstelle RowSet erbt von ResultSet – und schreibt weiteres Verhalten vor. In erster Linie ist sie als Container für Daten gedacht. Da sie ein ResultSet ist, kann sie natürlich alles, was ein normales ResultSet auch kann: mittels getXXX() Daten besorgen und mit updateXXX() Daten aktualisieren. Aber als Container verhält sie sich wie eine JavaBean, und an sie lassen sich Listener hängen. Sie informieren, wann etwa Elemente eingeführt oder gelöscht werden. Falls es beispielsweise eine Visualisierung gibt, kann sie sich abhängig von den Veränderungen immer informieren lassen und die neuen Werte anzeigen. Zwar kann ein scrollendes ResultSet auch den Cursor nach oben bewegen und ihn an eine beliebige Position setzen, das RowSet kann das aber immer, auch wenn das ResultSet diese Eigenschaft nicht hat.
Zusätzlich lässt sich ein RowSet auch serialisieren und ist prinzipiell nicht an Datenbanken gebunden, und die Daten können auch von einer Excel-Tabelle kommen. Jedes RowSet hat seine eigenen Metadaten, die durch ein RowSetMetaDataImpl-Objekt implementiert werden.
16.8.2 Implementierungen von RowSet
Um ein RowSet aufzubauen, gibt es unterschiedliche Implementierungen. Da es ein Aufsatz auf die JDBC-API ist, ist es auch nicht mit einem Treiber verbunden, sondern kann unabhängig vom Treiber implementiert werden – die Umsetzung ist generisch. Auch gibt es nicht nur ein RowSet, sondern wir unterscheiden zwischen verschiedenen Typen, die als Unterschnittstellen von javax.sql.RowSet im Paket javax.sql.rowset deklariert sind:
- JDBCRowSet ist ein kleiner Wrapper um das ResultSet, um es als JavaBean zugänglich zu machen. Eine Verbindung zur Datenbank muss bestehen.
- Ein CachedRowSet benötigt initial eine Verbindung zur Datenbank, um mit einer SQL-Anweisung automatisch alle Daten zu lesen. Anschließend ist keine Verbindung zur Datenbank nötig, wobei geänderte Daten später zurückgespielt werden können. Das ist perfekt in solchen Fällen, in denen Daten auf ein mobiles Endgerät wandern, dort Änderungen erfahren und diese später wieder eingespielt werden sollen.
- Ein WebRowSet erweitert CachedRowSet und bildet Daten und Operationen in XML ab, um sie zum Beispiel für Web-Services übertragen zu können.
- Das FilteredRowSet ist ein WebRowSet und ermöglicht eine zusätzliche Selektion mit Prädikaten.
- Ein JoinRowSet ist ebenfalls ein spezielles WebRowSet, das Daten unterschiedlicher RowSet-Schnittstellen wie über ein SQL-JOIN verbinden kann.
Seit Java 7 liefert der RowSetProvider.createFactory() eine Implementierung von RowSetFactory, das mit unterschiedlichen createXXXRowSet()-Methoden die Row-Sets liefert. Vor Version 7 liefert Java zwar Implementierungen der RowSet-Schnittstellen mit, doch das waren com.sun.rowset.XXXSetImpl-Klassen. Einige Datenbankhersteller liefern eigene Implementierungen mit aus, die vor Java 7 dann explizit angesprochen werden mussten.
16.8.3 Der Typ CachedRowSet
Um ein CachedRowSet aufzubauen, das keine dauerhafte Verbindung zur Datenbank benötigt, ist zunächst mit RowSetProvider.newFactory().createCachedRowSet() ein Implementierung von CachedRowSet aufzubauen. Anschließend ist dem Objekt zu sagen, welcher Datenbank welche Daten zu entnehmen sind. Wie üblich muss vorher der Treiber geladen sein:
Listing 16.7: com/tutego/insel/jdbc/CachedRowSetDemo.java, main()
CachedRowSet crset = RowSetProvider.newFactory().createCachedRowSet();
crset.setDataSourceName( "TutegoDS" );
crset.setCommand( "SELECT * FROM Customer" );
crset.execute();
Kommen die Daten nicht aus einer DataSource, bestimmt setUrl() die JDC-URL. In beiden Fällen können setUsername() und setPassword() den Benutzernamen und das Passwort angeben. Damit die Bean weiß, welche Daten sie aufnehmen soll, ist eine SQL-Anweisung zu formulieren. Der Aufruf execute() füllt das CachedRowSet (mit einem Logger lässt sich gut beobachten, dass die Datenbankverbindung auf- und dann wieder abgebaut wird). Falls eine Verbindung zur Datenbank schon besteht, kann bei execute() auch ein Connection-Objekt übergeben werden. Das CachedRowSet führt dann die gesetzte Anweisung über die bestehende Connection aus und überträgt die Daten aus der Datenbank in die Bean.
Wie aus ResultSet bekannt ist, lässt sich mit next() durch die Ergebnismenge eines RowSet iterieren:
while ( crset.next() )
System.out.println( crset.getString(1) );
crset.close();
Eine Position zurück geht previous(). Absolute Positionierung ist erlaubt und mit der Methode absolute(int position) möglich. Die aktuelle Zeile liefert getRow(), und die Anzahl geladener Zeilen liefert size(). Mit den updateXXX()-Methoden lassen sich Zeilen ändern. Vor einer Bewegung des Cursors muss updateRow() die Änderung bestätigen. Grundsätzlich müssen Änderungen mit setConcurrency() angekündigt sein, denn der Standardmodus ist ResultSet.CONCUR_READ_ONLY:
Änderungen werden an die Datenbank nur mit einer speziellen Methode zurückgeschrieben, die in der Regel am Ende aller Operationen aufgerufen wird: acceptChanges(). Spätestens dann muss es wieder eine Verbindung zur Datenbank geben.
crset.acceptChanges();
Veränderte Werte werden dann in der Datenbank aktualisiert und überschrieben. Wiederum ist auch eine Variante mit einem Connection-Parameter implementiert, die die Daten zu einer existierenden Datenbankverbindung schreibt.
16.8.4 Der Typ WebRowSet
Das WebRowSet schreibt zusätzlich zur Oberschnittstelle CachedRowSet nur zwei Arten von Operationen vor: readXml() und writeXml(). Die Lese-Methoden übertragen aus unterschiedlichen Datenquellen – etwa InputStream oder Reader – die Daten auf das WebRowSet. Die Schreibmethoden schreiben das RowSet in einen OutputStream oder Writer:
Listing 16.8: com/tutego/insel/jdbc/WebRowSetDemo.java, main()
WebRowSet data = RowSetProvider.newFactory().createWebRowSet();
data.setDataSourceName( "TutegoDS" );
data.setCommand( "SELECT * FROM Customer" );
data.setMaxRows( 2 );
data.execute();
data.writeXml( System.out );
data.close();
Die (gekürzte) Ausgabe sieht so aus:
<?xml version="1.0"?>
<webRowSet xmlns="http://java.sun.com/xml/ns/jdbc" xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/jdbc http://java.sun.com/xml/ns/jdbc/
webrowset.xsd">
<properties>
<command>SELECT * FROM Customer</command>
<concurrency>1008</concurrency>
<datasource>TutegoDS</datasource>
<escape-processing>true</escape-processing>
<fetch-direction>1000</fetch-direction>
<fetch-size>0</fetch-size>
<isolation-level>2</isolation-level>
<key-columns>
</key-columns>
<map>
</map>
<max-field-size>0</max-field-size>
<max-rows>2</max-rows>
<query-timeout>0</query-timeout>
<read-only>true</read-only>
<rowset-type>ResultSet.TYPE_SCROLL_INSENSITIVE</rowset-type>
<show-deleted>false</show-deleted>
<table-name>Customer</table-name>
<url><null/></url>
<sync-provider>
<sync-provider-name>com.sun.rowset.providers.
RIOptimisticProvider</sync-provider-name>
<sync-provider-vendor>Sun Microsystems Inc.</sync-provider-vendor>
<sync-provider-version>1.0</sync-provider-version>
<sync-provider-grade>2</sync-provider-grade>
<data-source-lock>1</data-source-lock>
</sync-provider>
</properties>
<metadata>
<column-count>5</column-count>
<column-definition>
<column-index>1</column-index>
<auto-increment>false</auto-increment>
<case-sensitive>false</case-sensitive>
<currency>false</currency>
<nullable>0</nullable>
<signed>true</signed>
<searchable>true</searchable>
<column-display-size>11</column-display-size>
<column-label>ID</column-label>
<column-name>ID</column-name>
<schema-name>PUBLIC</schema-name>
<column-precision>10</column-precision>
<column-scale>0</column-scale>
<table-name>CUSTOMER</table-name>
<catalog-name></catalog-name>
<column-type>4</column-type>
<column-type-name>INTEGER</column-type-name>
</column-definition>
<column-definition> ... </column-definition>
<column-definition> ... </column-definition>
<column-definition> ... </column-definition>
<column-definition> ... </column-definition>
</metadata>
<data>
<currentRow>
<columnValue>0</columnValue>
<columnValue>Laura</columnValue>
<columnValue>Steel</columnValue>
<columnValue>429 Seventh Av.</columnValue>
<columnValue>Dallas</columnValue>
</currentRow>
<currentRow>
<columnValue>1</columnValue>
<columnValue>Susanne</columnValue>
<columnValue>King</columnValue>
<columnValue>366 – 20th Ave.</columnValue>
<columnValue>Olten</columnValue>
</currentRow>
</data>
</webRowSet>
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.