Galileo Computing :: Java ist auch eine Insel – 22.9 ResultSets in Bohnen durch RowSet

22.9 ResultSets in Bohnen durch RowSet

Ein ResultSet haben wir als Informanten für Zeileninformationen kennengelernt. Mit einem Cursor konnten wir über Zeilen laufen und auch scrollen, wenn positionierbare Cursor angemeldet waren. Updates waren ebenfalls möglich gewesen. 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 Grunde implementiert ResultSet auch nicht die Schnittstelle Serializable.

22.9.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 es als Container für Daten gedacht. Da es ein ResultSet ist, kann es natürlich alles, was ein normales ResultSet auch kann: mittels getXXX() Daten besorgen und mit updateXXX() Daten aktualisieren. Aber als Container verhält es 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 etwa 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 Meta-Daten, die durch ein RowSetMetaDataImpl-Objekt implementiert werden.

22.9.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 Sun unterscheidet zwischen verschiedenen Typen. Sie sind als Unterschnittstellen von javax.sql.RowSet im Paket javax.sql.rowset deklariert:

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 den Fällen, wenn 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.

Der FilteredRowSet ist ein WebRowSet und ermöglicht zusätzliche Selektion mit Prädikaten.

Ein JoinRowSet ist ebenfalls ein spezielles WebRowSet, das Daten unterschiedlicher RowSets wie über ein SQL-JOIN verbinden kann.

Sun liefert seit Java 5 Implementierungen der RowSet-Schnittstellen mit; sie enden auf -Impl. Einige Datenbankhersteller liefern eigene Implementierungen mit aus.

22.9.3 Der Typ CachedRowSet

Um ein CachedRowSet aufzubauen, das keine dauerhafte Verbindung zur Datenbank benötigt, ist zunächst ein einfaches CachedRowSetImpl-Objekt mit dem Standardkonstruktor aufzubauen. Anschließend ist dem Objekt zu sagen, aus welcher Datenbank welche Daten zu entnehmen sind. Wie üblich muss vorher der Treiber geladen sein.

Listing 22.10 com/tutego/insel/jdbc/CachedRowSetDemo.java, main()

CachedRowSet crset = new CachedRowSetImpl(); 
crset.setDataSourceName( "UllisDS" ); 
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 RowSets 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 Funktion absolute(int position) möglich. Die aktuelle Zeile liefert getRow(), und die Anzahl geladener Zeilen liefert size(). Mit den updateXXX()-Funktionen 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.

crset.setConcurrency( ResultSet.CONCUR_UPDATABLE );

Änderungen werden an die Datenbank nur mit einer speziellen Funktion 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.

22.9.4 Der Typ WebRowSet

Das WebRowSet schreibt zusätzlich zur Ober-Schnittstelle 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 22.11 com/tutego/insel/jdbc/WebRowSetDemo.java, main()

WebRowSet data = new WebRowSetImpl(); 
data.setDataSourceName( "UllisDS" ); 
data.setCommand( "SELECT * FROM Customer" ); 
data.setMaxRows( 2 ); 
data.execute(); 
data.writeXml( System.out ); 
data.close();

Die (gekürzte) Ausgabe:

<?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>UllisDS</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.