7 Datenbankabfragen. 7.1 Die Hibernate Query Language

Transkript

1 149 Dieses Kapitel widmet sich dem effektiven Zugriff auf Daten. Mit Datenbankabfragen können Objekte mit bestimmten Eigenschaften gesucht werden. Erst mit Abfragen ist es möglich, Objekte zu laden, deren ID nicht bekannt ist. Es werden die drei Möglichkeiten beschrieben, wie Abfragen definiert und ausgeführt werden können. Zuerst wird die Hibernate Query Language (HQL) erläutert. Wir zeigen auch die programmatische Form der Abfrage mit Queries und Criterias. Außerdem zeigen wir, wie in Hibernate SQL-Abfragen genutzt werden können. Zum Ende des Kapitels werden Filter beschrieben, welche die Ergebnismenge von Abfragen einschränken. Für die Beispiele wird in dem Kapitel das einfache Beispiel weiter verwendet. Wie in der folgenden Abbildung verwenden wir Termine, die ihre Teilnehmer kennen. Überblick Abb. 7 1 Termin und Benutzer 7.1 Die Hibernate Query Language Die Syntax der HQL ist der von SQL sehr ähnlich. Groß- und Kleinschreibung ist für die Schlüsselwörter der HQL unerheblich. Für die weiteren Beispiele werden wir Kleinschreibung benutzen. Die einfachste Abfrage mit der HQL ist in unserem Fall die folgende: from Termin gleichbedeutend zu FROM Termin

2 150 Query ausführen Diese ganz einfache Abfrage liefert alle Termine aus der Datenbank und wird mit dem Befehl createquery an einer Session erzeugt: Query q = session.createquery( from Termine ); List<Termin> alletermine = q.list(); Die Ausführung der Query wird erst mit einer der Methoden list, scroll oder iterator gestartet. Ausführung der Query Befehl list() iterator() scroll() uniqueresult() Ergebnis Liefert eine Liste der Ergebnisse vom Typ java.util.list Liefert einen Iterator über die Ergebnisse vom Typ java.util.iterator Bietet die Möglichkeit, innerhalb des Ergebnisses zu blättern, liefert als Typ org.hibernate.scrollableresults Nützlich, wenn die Abfrage nur ein Ergebnis liefern kann, ist entweder null oder vom Typ java.lang.object Falls mehrere Ergebnisse gefunden werden, wird eine Exception geworfen! Ergebnis der Abfrage auto-import Eine Query kann nur mit den beschriebenenen Methoden ausgeführt werden, solange die erzeugende Session aktiv und nicht geschlossen ist. Die gefundenen Objekte befinden sich im persistenten Zustand, solange die Session nicht beendet wurde. Daher werden Änderungen an Objekten auch gespeichert, wenn diese durch eine Abfrage bezogen wurden und die Session aktiv ist. Das Ergebnis der obigen Abfrage from Termin sind alle Termine, die in der Datenbank gespeichert sind. In der from-klausel wird der Typ der Objekte angegeben, nach denen gesucht wird. Als Bezeichnung wird der Name des Typs angegeben. Es ist zu beachten, dass bei der Angabe des Typs auf Groß- und Kleinschreibung unterschieden wird. Die Schreibweise muss der der Klasse bzw. des Interfaces entsprechen! Im Beispiel haben wir den Typ Termin ohne das Package angegeben. Der Name des Typs muss in der Abfrage nur voll qualifiziert angegeben werden, wenn in der Mapping-Datei explizit das Attribut auto-import= false gesetzt wurde. Ansonsten sucht Hibernate nach dem Typ in allen Klassen und Interfaces, die bei der Configuration angemeldet sind 1. Dadurch können die Typen in den Abfrage ohne volle Qualifizierung angegeben werden.

3 7.1 Die Hibernate Query Language 151 Wird innerhalb mehrerer Objekttypen gesucht, werden diese durch Kommata getrennt. Das entspricht einem Join in SQL. Um diese Objekttypen in anderen Teilen der Abfrage zu referenzieren, wird nach dem Objekttyp ein Alias angegeben. Dieses Alias steht dann stellvertretend in der Abfrage für alle persistenten Objekte dieses Typs. Zur besseren Lesbarkeit darf optional»as«dazwischen stehen. Aliase from Termin as termin from Termin termin, Benutzer benutzer Sind in der from-klausel einer Abfrage mehrere Typen angegeben, werden die Ergebnisse als Liste von Arrays geliefert. Die nächste Abfrage liefert alle Kombinationen von Terminen und Benutzern als Liste von Arrays: Tupel Query q = session.createquery( from Termin, Benutzer ); List tupel = q.list(); Object[] arr = (Object[]) tupel.get(0); Termin termin = arr[0]; Benutzer benutzer = arr[1]; Die Abfragen können auf Ergebnisse mit bestimmten Eigenschaften eingeschränkt werden. Wie in SQL gibt eine where-klausel die Bedingung an, die für das Ergebnis zutreffen muss. Mit der folgenden Abfrage finden wir alle Termine, die im»raum 123«stattfinden: from Termin as term where term.ort = Raum 123 Der Bezeichner»ort«in der obigen Abfrage bezieht sich auf das gleichnamige Property der Klasse Termin und nicht auf den Spaltennamen in der Tabelle! Genauso bezieht sich der Bezeichner Termin auf den Namen der Klasse und nicht auf den Tabellennamen. Achtung Um Attribute von enthaltenen Objekten mit in die Abfrage einzubeziehen, werden sie einfach mit einem Punkt verknüpft. Als Beispiel suchen wir nach allen Terminen für einen Benutzer. Bei der Abfrage soll nur dessen Kürzel bekannt sein. Die Abfrage für die Termine des Benutzers, mit dem Kürzel»rb«lautet dann wie folgt: from Termin t where t.teilnehmer.kuerzel = rb 1. Wenn gleichnamige Klassen in unterschiedlichen Packages mit Hibernate verwaltet werden, muss auto-import ausgeschaltet werden, ansonsten ist der Typname für die Abfragen nicht eindeutig, und es wird eine Exception geworfen.

4 152 Kriterien Für die Beschreibung der Kriterien stehen die Standard-SQL-Operatoren zur Verfügung: =, <>, <, >, >=, <=, like, between, not between, in und not in. Folgendes Beispiel zeigt eine Abfrage aller Termine, deren Property Ort mit dem String»Raum A«anfängt: from Termin term where term.ort like Raum A% Wie man sieht, wird die Wildcard % aus SQL auch in HQL für das String-Kriterium like verwendet und steht für beliebig viele Zeichen. Mehrere Kriterien werden innerhalb der where-klausel mit den booleschen Operatoren and, or und not verknüpft und können mit Klammern gruppiert werden. Das folgende Beispiel liefert alle Termine, die in der Beschreibung mit»projekt Hibernate«anfangen und in Hamburg oder Berlin stattfinden: from Termin termin where termin.beschreibung like Projekt Hibernate% and (termin.ort = Hamburg or termin.ort= Berlin ) Die obige Abfrage lässt sich auch mit dem in-operator formulieren: from Termin termin where termin.beschreibung like Projekt Hibernate% and termin in ( Hamburg, Berlin ) Der in-operator kann wie alle anderen Operatoren mit not negiert werden. Die folgende Abfrage findet somit alle Termine mit der obigen Beschreibung, die weder in München noch in Köln stattfinden: from Termin termin where termin.beschreibung like Projekt Hibernate% and termin not in ( München, Köln ) Eine weitere Möglichkeit, ein Kriterium zu bestimmen, sind Funktionen. Die folgende Abfrage liefert alle Termine, für die mindestens zwei Teilnehmer eingetragen sind. from Termin t where size(t.teilnehmer) > 2 Mit empty ist es sehr einfach abzufragen, ob eine Collection leer ist. So können mit der Abfrage alle Termine gefunden werden, für die keine Teilnehmer eingetragen sind: from Termin t where t.teilnehmer is empty Select Sind für die Abfrage nur Objekte eines bestimmten Typs erforderlich, werden vor der from-klausel mit einer select-klausel die Ergebnistypen ausgewählt. Im Vergleich zu SQL ist die select-klausel bei der Hibernate Query Language optional. In der select-klausel werden die Aliase

5 7.1 Die Hibernate Query Language 153 der Objekte angegeben, die als Ergebnis für die Abfrage von Interesse sind. Die nächste Abfrage liefert z.b. alle Benutzer als Liste, die bei Terminen mit der Beschreibung»Buchbesprechung«eingetragen sind: select t.teilnehmer from Termin as t where t.beschreibung = Buchbesprechung Eine Abfrage wie from Termin bezieht sich auf alle in der Datenbank gespeicherten Objekte des Typs Termin. Bei der Abfrage werden auch sämtliche Subklassen von Termin aus der Datenbank geladen, die der Session bzw. der Configuration bekannt sind. Als Typ kann natürlich auch ein Interface angegeben werden. Das Ergebnis bezieht dann alle persistenten Objekte mit ein, die dieses Interface implementieren. Polymorphe Abfragen werden in HQL immer identisch formuliert, unabhängig von der Abbildung der Vererbungshierarchie. Hibernate muss bei polymorphen Anfragen mehrere SQL-Statements an die Datenbank schicken. Es ist zu beachten, dass in den Resultaten nicht mit dem Befehl scroll geblättert werden kann! Polymorphe Abfragen Achtung Nicht bei jeder Anfrage stehen zur Zeit der Programmierung die Kriterien fest. Häufig ist es notwendig, der Abfrage zur Laufzeit Parameter für die Kriterien zu übergeben. Hibernate bietet zwei Möglichkeiten, Parameter anzugeben. Ein Parameter kann in einer Abfrage mit einem Fragezeichen als Platzhalter angegeben werden. Anstelle dieses Platzhalters muss der Query zur Laufzeit vor der Ausführung der Abfrage ein Wert- oder ein kompatibles Objekt übergeben werden. Damit mehrere Parameter pro Abfrage benutzt werden können, übergibt man diese nummeriert der Query. Um Termine z.b. nach Ort zu suchen, würde man folgende Abfrage stellen: Parameter String gesuchterort = xyz.getgesuchterort(); Query q = session.createquery( from Termin termin + where termin.ort =? ); q.setstring(0, gesuchterort); List gefundenetermine = q.list(); Bei Hibernate fängt die Nummerierung von Parametern immer bei 0 an und verhält sich somit wie Arrays oder die Collections aus dem JDK. Bei JDBC wird dagen die 1 für den ersten Parameter verwendet! Achtung

6 154 Benannte Parameter Entitäten als Parameter Sortierung Hibernate bietet auch die Möglichkeit, benannte Parameter zu benutzen. Ein benannter Parameter wird in der HQL mit einem Doppelpunkt eingeleitet. Diese benannten Platzhalter erhöhen die Lesbarkeit und verringern die Fehleranfälligkeit bei Abfragen. Die gleiche Abfrage mit einem benannten Parameter sieht wie folgt aus: String gesuchterort = xyz.getgesuchterort(); Query q = session.createquery( from Termin termin + where termin.ort = :ort ); q.setstring( ort, gesuchterort); List gefundenetermine = q.list(); Einer Query kann auch eine Entität als Suchparameter übergeben werden. Für den Platzhalter wird der Query ein bereits geladenes Objekt eingesetzt. Hibernate erzeugt für die Query selbstständig die Verknüpfung in seiner SQL-Abfrage. Es kann damit z.b. nach allen Terminen für einen bestimmten Ort gesucht werden: Ort ort = xyz.getgesuchterort(); Query q = session.createquery( from Termin termin + where termin.ort = :ort ); q.setentity( ort, ort); List gefundenetermine = q.list(); Die Ergebnisse einer Abfrage können sortiert werden. Dazu wird nach der from- und der where-klausel der Befehl order by angegeben, mit einem Attribut, nach dem sortiert werden soll. Das entspricht genau dem order by in SQL. Zusätzlich kann mit asc oder desc angegeben werden, ob auf- oder absteigend sortiert werden soll. Wird zu dem Befehl order by weder asc noch desc angegeben, wird aufsteigend sortiert (asc). Sind mehrere Sortierkriterien erwünscht, werden sie in absteigender Rangfolge mit Kommata getrennt angegeben. Die obige Anfrage suchte nach Terminen mit einem bestimmten Ort. Diese Anfrage sieht wie folgt aus, wenn sie um eine Sortierung nach dem Anfang erweitert wird: from Termin termin where termin.ort = :ort order by termin.anfang Joins Bei einer Abfrage, die sich auf mehrere Typen bezieht, werden die Tabellen zum kartesischen Produkt verknüpft. Alle möglichen Kombinationen der Zeilen der beteiligten Tabellen werden dabei kombiniert. Die Auswahl der gelieferten Kombinationen wird durch die unterschiedlichen Join-Typen bestimmt. Bei einem Join werden die gesuchten Typen in der from-klausel angegeben. Die Basis der Abfrage bilden alle möglichen Kombinationen zwischen den angegebenen Typen.

7 7.1 Die Hibernate Query Language 155 Die folgende Abfrage liefert alle Termine und Benutzer, die sich in Berlin treffen. Die Ergebnisse sind Arrays mit jeweils dem Termin und einem der Teilnehmer. from Termin t inner join t.teilnehmer where t.ort = Berlin Um alle Termine zu bekommen, auch die ohne Teilnehmer, ist ein left outer join notwendig. In dem Ergebnis sind jetzt auch Termine ohne Teilnehmer enthalten. Das Ergebnis ist eine Liste von Arrays. Bei den Terminen ohne Teilnehmer ist das Feld des Arrays für die Teilnehmer null. from Termin t left outer join t.teilnehmer where t.ort = Berlin Ein right outer join liefert alle Kombinationen zwischen den beiden Tabellen und alle Einträge aus der zweiten Tabelle, für die es keinen entsprechenden Eintrag in der ersten Tabelle gibt. Die folgende Abfrage liefert eine Liste aller Benutzer, die einen Termin in Berlin eingetragen haben. Die Abfrage enthält keinen Join- Befehl. Hibernate macht intern einen Join über die Fremdschlüssel- Tabelle für die Benutzer und die Einschränkung auf den Ort. Daher wird diese Art auch impliziter Join genannt. select t.teilnehmer from Termin t where t.ort = Berlin Es gibt die Möglichkeit, Queries in Mapping-Dateien zu definieren, anstatt diese im Progammcode zu schreiben. Diese können dann unabhängig vom Rest des Programms weiterentwickelt und optimiert werden. Eine solche Named Query wird direkt an der Session mit der Methode getnamedquery bezogen. Benannte Queries Ort ort = xyz.getgesuchterort(); Query q = session.getnamedquery( alletermine ); q.setentity( ort, ort); List alletermine = q.list(); Wie in dem Beispiel zu sehen, entfällt der lange Text der eigentlichen Query im Programmcode. Als Nachteil ist sofort ersichtlich, dass die Namen der Parameter im Programmtext nicht erkennbar sind! Die Query wird in der Mapping-Datei durch das Element <query> definiert und mit dem Attribut name als»alletermine«benannt. Die eigentliche Query wird zusätzlich in einem CDATA-Element verpackt:

8 156 <query name= alletermine > <![CDATA[from Termin as t where t.ort = :ort ]]> </query> Projektion Genauere Angaben zu den Mapping-Dateien und deren Syntax sind in Kapitel 4 zu finden. Für Auswertungen und Berichte sind bei einer Abfrage nicht immer die kompletten Objekte mit allen Attributen notwendig. Auch wird bei diesen Abfragen nicht die transparente Persistenz benötigt, um geladene Objekte ändern zu können. Bei diesen Abfragen wird nur ein Teil der Werte aus den Ergebnissen benötigt. Das wird Projektion genannt. In der select-klausel dürfen auch ausgewählte Attribute eines gesuchten Objektes angegeben werden. Diese Attribute werden in der Ergebnisliste dann als Array geliefert. Das Ergebnis ist nur ein aktuelles Abbild der Daten, es hat für Hibernate keinen Zustand und keine transparente Persistenz. Somit werden Änderungen an diesen Daten nicht wieder in die Datenbank geschrieben. Das folgende Beispiel liefert den Titel, die Anfangszeit und die Beschreibung aller Termine: Query q = session.createquery( select t.titel, termin.anfang, termin.beschreibung + from Termin as termin ); List<Object[]> uebersicht = q.list(); for (Object[] zeile : uebersicht) { String titel = (String) zeile[0]; Date anfang = (Date) zeile[1]; String beschreibung = (String) zeile[2];... } Gruppierungen und Zusammenfassungen In unserem Beispiel kann es gewünscht sein, dass wir in einem Bericht die Anzahl der Termine pro Ort ausgeben. Wir wollen die Frage beantworten, in welchen Städten die meisten Termine stattfinden, um damit eine Rangliste zu erzeugen. Anstatt alle Objekte zu laden, zu vergleichen, Termine zu addieren usw., können wir eine Abfrage mit Gruppierung benutzen.

9 7.1 Die Hibernate Query Language 157 Query q = session.createquery( select termin.ort, count(termin) + from Termin as termin group by termin.ort + order by count(termin) desc ); List<Object[]> uebersicht = q.list(); for (Object[] zeile : uebersicht) { String ort = (String) zeile[0]; int anzahl = (Integer) zeile[1]; System.out.println("Stadt=" + ort + ", Anzahl Termine=" + anzahl); } In der Abfrage werden alle Orte ausgewählt und nach den Orten gruppiert. Die Aggregatsfunktion count() zählt alle Einträge, die in dieselbe Gruppierung fallen. In diesem Fall zählen wir die Termine mit dem gleichen Ort. Bei der order-by-klausel darf auch die Aggregatsfunktion verwendet werden, damit nach deren Ergebnis sortiert wird. Das Beispiel sortiert absteigend nach der Anzahl der Termine pro Gruppierung. Neben count() gibt es noch die folgenden Aggregatsfunktionen: Aggregatsfunktionen Funktion count() min() max() sum() avg() Zweck Berechnet die Anzahl der Elemente in der Gruppierung Bestimmt das Minimum der Elemente in der Gruppierung Bestimmt das Maximum der Elemente in der Gruppierung Summiert die Elemente in der Gruppierung Berechnet den Mittelwert Eine Aggregatsfunktion ist entweder mit einer Gruppierung kombiniert oder bezieht sich auf alle Ergebnisse der Abfrage. Wenn keine Gruppierung angegeben wird, dann gibt es nur ein Ergebnis. Die in der select-klausel ausgewählten Attribute dürfen in diesem Fall dann auch nur Aufrufe von Aggregatsfunktionen sein! So kann als Beispiel die Abfrage dienen, um zu erfahren, wie viele Termine in einer gegebenen Stadt geplant sind: Query query = session.createquery("select count(t) + from Termin as t where t.ort = :ort"); query.setstring("ort", "Berlin"); int anzahl = (Integer) query.uniqueresult();

10 158 Blättern Nicht jede Anfrage liefert eine überschaubare Anzahl von Ergebnissen. Mitunter können die Ergebnisse sehr lange Listen sein, die komplett geladen den Speicher der Anwendung überlasten würden. Hibernate bietet zwei Ansätze, diesem Problem bei Abfragen zu begegnen. Das Ergebnis einer Query kann durch eine untere Schranke eingegrenzt werden. Dazu kann die maximale Anzahl von Ergebnissen angegeben werden. Query q = session.createquery( from Termin ); q.setfirstresult(90); q.setmaxresults(10); List<Termin> termine = q.list(); In diesem Beispiel wurde das Ergebnis auf zehn Termine eingeschränkt. Die ersten 90 Termine der Abfrage sollen ignoriert werden. Die Methode setfirstresult ist nullbasiert wie alle Methoden in Hibernate mit Bezug auf Indizes. Der zweite Lösungsansatz liefert Queries, in denen geblättert werden kann. Die Methode scroll liefert das Ergebnis als ScrollableResults. Das Ergebnis kann sehr variabel iteriert werden. Ergebnisse können auch direkt angesprungen werden. Spätestens bei dem Zugriff auf ein bestimmtes Objekt wird dieses erst aus der Datenbank geladen. Das ScrollableResults hat einen Zeiger auf eine Zeile des Ergebnisses, der mit den Methoden next, first, scroll, previous, last, beforefirst, afterlast und setrownumber verschoben werden kann. Entsprechend der select-klausel der Anfrage können in jeder Zeile der Ergebnisse mehrere Objekte sein. Auf das aktuell selektierte Ergebnis wird immer indiziert zugegriffen, auch wenn pro Zeile nur ein Objekt ausgewählt wird. Folgende Abfrage liefert eine Übersicht der Benutzer, bei der nur jeder zwanzigste angegeben wird: Query q = session.createquery( select b.nachname + from Benutzer b + order by b.nachname ); ScrollableResults ergebnis = q.scroll(); List<String> benutzer = new ArrayList<String>(); if (ergebnis.first()) { do { benutzer.add(ergebnis.getstring(0)); } while(ergebnis.scroll(20)); }

11 7.2 Typsichere Abfragen mit Criteria 159 Wird über ein ScrollableResults iteriert und auf enthaltene Objekte zugegriffen, muss die Session noch aktiv sein. Das ScrollableResults kann nur benutzt werden, wenn der eingesetzte JDBC-Treiber Blättern unterstützt. Bisher wurden mit der HQL nur Objekte und Daten ausgelesen. Es ist auch seit Hibernate 3 möglich, mit einer Abfrage zu ändern und zu löschen. Sollen z.b. alle Termine aus Berlin nach Hamburg verlegt werden, kann das wie folgt passieren: Ändern und Löschen Query q = session.createquery( update Termin + set ort = :neuerort where ort = :alterort ); q.setstring( alterort, Berlin ); q.setstring( neuerort, Hamburg ); q.executeupdate(); Auf das Schlüsselwort update folgt der zu ändernde Typ. Dem folgen der Befehl set und die Zuweisung der zu ändernden Attribute. Abschließend kann mit einem where ein Kriterium angegeben, das die Änderung einschränkt. Mit der Methode executeupdate wird diese Form einer verändernden Abfrage ausgeführt. Die Methode liefert als Ergebnis die Anzahl der veränderten Objekte. Mit der HQL können auch Objekte gelöscht werden, die bestimmten Kriterien entsprechen. Somit können auch Objekte gelöscht werden, die nicht geladen sind. Alle Termine, die in München stattfinden sollen, werden mit dem folgenden Beispiel gelöscht: Query q = session.createquery( delete Termin + where ort = :ort ); q.setstring( ort, München ); q.executeupdate(); Auch bei dem Löschen wird die verändernde Query mit der Methode executeupdate ausgeführt. Bei einer ändernden Abfrage dürfen sowohl die Änderung als auch das Kriterium sich dabei nur auf einen Typ beziehen. Subtypen und enthaltene Objekte dürfen nicht mit in eine ändernde Abfrage einbezogen werden! Achtung 7.2 Typsichere Abfragen mit Criteria Hibernate bietet mit Criterias eine programmatische Möglichkeit, Abfragen zu definieren. An der Session kann ein Criteria erzeugt wer-

12 160 den, dabei muss der Ergebnistyp angegeben werden. Das einfachste Criteria, das alle Benutzer als Liste liefert, ist das folgende: Criteria criteria = session.createcriteria(benutzer.class); List<Benutzer> benutzer = criteria.list(); Es sind bei den programmatischen Abfragen mit Criterias Einschränkungen der Ergebnismenge durch Kriterien möglich. Die Klasse Restrictions aus dem Package org.hibernate.criterion ist eine Fabrik für solche Kriterien. Die folgende Abfrage liefert alle Termine aus Hamburg: Criteria crit = session.createcriteria(termin.class); c.add(restrictions.eq("ort", "Hamburg")); List<Termin> termine = criteria.list(); Diese Kriterien liefern als Rückgabewert immer wieder das geänderte Criteria-Objekt. Somit können komplexere Abfragen mit einem Java- Statement definiert werden. Das folgende Beispiel zeigt, wie mit einem einzigen Statement alle Termine aus Hamburg als Liste geliefert werden, die in der Beschreibung»Hibernate«enthalten: List liste = session.createcriteria(termin.class).add(restrictions.eq("ort", "Hamburg")).add(Restrictions.like( beschreibung, %Hibernate% )).list(); Diese Abfrage kann vereinfacht werden durch das neue Feature des statischen Imports in Java 5. Damit können die statischen Methoden und Attribute der importierten Klasse ohne Qualifizierung durch den Namen der Klasse benutzt werden. import static org.hibernate.criterion.restrictions.*;... List liste = session.createcriteria(termin.class).add(eq("ort", "Hamburg")).add(like( beschreibung, %essen% )).list(); Gruppierung Mit der Criteria-API können auch Gruppierungen in Abfragen erzeugt werden. Ein Beispiel zur Gruppierung hatte die Anzahl der Termine pro Ort abgefragt. Dem Criteria muss eine Projection gesetzt werden. int anzahl = (Integer) session.createcriteria(termin.class).setprojection(projections.rowcount()).add(like("ort", "Berlin")).uniqueResult();

13 7.3 Abfragen mit SQL 161 Das Beispiel hat eine Gruppierung auf die gesamte Ergebnismenge. Um mit Criterias für jeden Ort die Anzahl der Termine auszugeben, wird nach dem Ort gruppiert. Um eine Projektion auf mehrere Attribute und Aggregierungen zu erreichen, muss eine ProjectionList benutzt werden. Das folgende Beispiel nutzt die Möglichkeit von Hibernate, die Befehle»aneinander zu ketten«. So liefert z.b. die Methode setprojection dasselbe Criteria als Ergebnis, an dem sie aufgerufen wurde: List<Object[]> list = session.createcriteria(termin.class).setprojection( Projections.projectionList().add(Projections.property("ort")).add(Projections.rowCount()).add(Projections.groupProperty("ort"))).list(); for (Object[] zeile : list) { String ort = (String) zeile[0]; int anzahl = (Integer) zeile[1];... } Abfragen mit Criterias bieten einen großen Vorteil, denn durch die Angabe des Typs als Class-Objekt bei der Erzeugung des Criterias bieten sie Typsicherheit. Werden Änderungen an dem Namen des Typs gemacht, fällt das schon zur Kompilierzeit auf. Für die Erstellung einer Abfrage ist keine Kenntnis von HQL oder von SQL notwendig. Wenn Abfragen optionale Kriterien enthalten, ist das mit Criterias einfacher zu lösen als mit HQL, wobei dort der Abfragetext jeweils angepasst werden muss. Criterias unterstützen keine Joins, sie sind somit nicht so mächtig wie Abfragen mit der HQL. Der Vorteil der Typsicherheit gilt nicht für die Angabe der Properties, diese müssen als String angegeben werden. Sie sind somit anfällig gegenüber Änderungen an den persistierten Klassen und werden zur Kompilierzeit nicht aufgedeckt. Abfragen mit Criterias sind nicht so»übersichtlich«wie HQL-Abfragen. Vor- und Nachteile 7.3 Abfragen mit SQL An der Session kann eine SQL-Query erzeugt werden. Das kann für mehrere Fälle sinnvoll sein: Stored Procedures sollen an der Datenbank aufgerufen werden. Auf die spezielle Datenbank optimierte Abfragen sollen gerufen werden. Bei der Umstellung von alten SQL-Abfragen auf HQL

14 162 Damit Hibernate den Bezug von der Abfrage zu den verwalteten persistenten Klassen bekommt, müssen diese der Query angegeben werden. In dem einfachsten Beispiel sollen mit SQL alle Termine ausgegeben werden: SQLQuery q = session.createsqlquery( select {termin.*} + from TERMIN {termin} ); q.addentity( termin, Termin.class); List termine = q.list(); Named Queries Als Erstes fällt die select-klausel auf. Die geschweiften Klammern sind Platzhalter für Hibernate. Und in der from-klausel wird der Tabellenname angegeben, nicht der Typ! In dem Beispiel werden Objekte vom Typ Termin mit allen Attributen erwartet, daher der Stern hinter dem Platzhalter termin. Es wäre hier auch möglich, durch die Angabe von Propertys an dieser Stelle nur einzelne Attribute aus der Datenbank auszulesen. An Stelle der Platzhalter werden die Spalten aus der Datenbank eingesetzt. Dies muss mit einer Benennung und Reihenfolge geschehen, die Hibernate kennt. Ansonsten könnte Hibernate aus dem Ergebnis kein Objekt des Typs Termin erzeugen. Hibernate muss den Hinweis bekommen, dass Objekte des Typs Termin gesucht werden. Durch den Aufruf der Methode addentity wird Hibernate dieser Hinweis gegeben, und der Typ Termin wird mit dem Platzhalter termin verbunden. Ansonsten ist SQLQuery eine Spezialisierung und Subklasse einer Query und kann genauso zur Auflistung des Ergebnisses verwendet werden. SQL-Queries können ähnlich wie HQL-Queries in der Mapping- Datei definiert werden. Die Query wird in einem sql-query-element mit einem Namen verpackt. <sql-query name= sqlalletermine > <return alias= termin class= de.abc.termin /> <![CDATA[ select {termin.*} from TERMIN {termin} ]]> </sql-query> Diese Query kann genau wie benannte HQL-Queries an der Session mit der Methode getnamedquery abgerufen werden. Einer SQL-Query können auch benannte und nummerierte Parameter mit übergeben werden. Der Typ des Rückgabewertes wird einer benannten Query nicht mehr im Programmcode gesetzt, er ist in der Definition mit dem Element return inklusive Alias angegeben.

15 7.4 Filter 163 Aus dem Beispiel ist schon ersichtlich, dass Abfragen mit HQL oder Criterias gegenüber Abfragen mit SQL vorzuziehen sind. Es ist umständlicher und unsicherer als HQL und Criterias, denn z.b. die Namen der Tabellen und Spalten müssen bekannt sein, polymorphe Abfragen und implizite Joins sind nicht möglich. SQL-Abfragen können in einer Migration für den Umstieg auf Hibernate geeignet sein. Außerdem ist es seit Hibernate 3 möglich, mit der Hilfe benannter SQL-Queries stored procedures aufzurufen. Vor- und Nachteile 7.4 Filter Filter bieten die Möglichkeit, für eine Session sämtliche Abfragen auf Ergebnisse mit bestimmten Kriterien einzuschränken. Ein Filter wird in der Mapping-Datei definiert. Nach der Mapping-Definition der Klassen gibt man dort den Namen und die Parameter des Filters an: </hibernate-mapping>... </class> <filter-def name= nureinort > <filter-param name= ort type= string /> </filter-def>... </hibernate-mapping> Hier wurden nur der Name und die Parameter eines Filters definiert. Innerhalb des Mappings für persistente Klassen und Collections kann dieser Filter mit Kriterien gefüllt werden. </hibernate-mapping>... <class name= Termin >... <property name="ort"/> <filter name="nureinort" condition="ort = :ort"/> </class> <filter-def name= nureinort > <filter-param name= ort type= string /> </filter-def>... </hibernate-mapping> Innerhalb des Mappings für die Klasse Termin wird jetzt für den Filter mit dem Namen nureinort eine Bedingung angegeben. Dieser Filter bestimmt die zurückgelieferten Termine, die von jeder Abfrage mit diesem Filter geliefert werden. In dem Beispiel müssen Ergebnisse in der Spalte ort den gleichen Wert haben wie der Parameter :ort.

16 164 Achtung Der Bezeichner»ort«für das obige Kriterium bezieht sich nicht auf das Property mit dem Namen Ort, sondern die gleichnamige Tabellenspalte! Filterkriterien beziehen sich direkt auf die Namen der Spalten und nicht wie sonst in Hibernate üblich auf die Namen der Properties. Da Filter in der Mapping-Datei definiert werden, ist an dieser Stelle der Name der entsprechenden Tabellenspalte bekannt. Um den eben definierten Filter zu aktivieren, muss dieser an der Session mit enablefilter aktiviert werden. Zusätzlich müssen an dem Filter die benötigten Parameter gesetzt werden. Filter ortfilter = session.enablefilter("nureinort"); ortfilter.setparameter("ort", "Hamburg"); List termine = session.createquery( from Termin ).list(); Hier in dem Beispiel wurden nur Termine aus Hamburg geliefert. Der Filter beschränkt nur die Ergebnisse von sondierenden Abfragen. Ist in dem System noch ein Objekt, das dem Filter nicht entspricht, z.b. ein Termin aus München, dann kann dieser mit delete an der Session gelöscht werden, obwohl der Filter aktiv ist. Genauso können noch Objekte mit ihrer ID geladen werden, deren Attribute nicht den Filterkriterien entsprechen. Wird ein Filter nicht mehr benötigt, deaktiviert man ihn mit der Methode disablefilter und dem Namen des Filters: session.disablefilter("nureinort"); Filter können in der Praxis mehrere sinnvolle Einsatzgebiete finden. In unserem Beispiel könnte man z.b. für bestimmte Umstände sämtliche Termine herausfiltern, die in der Vergangenheit stattfanden. 7.5 Referenzen [Hibernate] Die Hibernate-Website mit der Dokumentation bietet sehr viel Information zu Abfragen.