GEDOPLAN
Jakarta EE (Java EE)

Criteria Queries in JPA 2.0

Jakarta EE (Java EE)

JPA 2.0 bietet als eine der groß angekündigten Neuerungen sog. Criteria Queries an. Damit ist es möglich, Queries in objektorientierter Weise zusammenzusetzen und dabei die Vollständigkeit und die Typkorrektheit weitgehend zu garantieren.

Eine herkömmliche Query sähe bsw. so aus:

TypedQuery q = em.createQuery(“select e from SomeEntity e where e.name=’Hugo'”, SomeEntity.class);

Das ist zwar relativ einfach und überschaubar, birgt aber ein paar Stolperfallen:
– Ist die Query formal vollständig?
– Passen die selektierten Werte zum Typ der Query?
– Heißt das Attribut wirklich name?
– Hat das verglichene Attribut wirklich den Typ String?

Nichts davon kann zur Compilezeit geprüft werden, da dazu der JPQL-Text geparst werden muss. Das hier eingesetzte, neue, getypte Interface TypedQuery hilft hier auch nicht weiter; seine Vorteile liegen erst in der hier nicht gezeigten weiteren Verarbeitung der Query.

Als Criteria Query sähe das Beispiel so aus:

CriteriaBuilder builder = em.getCriteriaBuilder();

// Criteria Query für Ergebnistyp erzeugen
CriteriaQuery cQuery = builder.createQuery(SomeEntity.class);

// Projektionsvariablen erzeugen (FROM-Klausel)
Root c = cQuery.from(SomeEntity.class);

// Selektion angeben (SELECT-Klausel)
cQuery.select(c);

// Bedingung erstellen und der Query hinzufügen
Path cName = c.get(SomeEntity_.name);
Predicate hatNamen = builder.equal(cName, builder.parameter(String.class, “name”));
cQuery.where(hatNamen);

// Normale Query erstellen
TypedQuery q = em.createQuery(cQuery);

Was hat’s nun gebracht?

Zunächst kann man durch die geschickte Verflechtung der zu nutzenden Typen kaum etwas vergessen, die Query wird also formal vollständig sein. Man könnte im Beispiel höchstens die SELECT-Klausel vergessen, was zur Compilezeit deshalb nicht geprüft werden kann, da eine Query ja nicht in jedem Fall etwas selektiert.

Im Falle der SELECT-Klausel sieht man aber bereits einen Vorteil: Versucht man hier etwas zu selektieren, was nicht zum Typ der Query passt, ist ein Compile-Fehler die Folge.

Beim Aufbau der WHERE-Bedingung, genauer des darin genutzten Prädikats, werden zwei weitere Vorteile deutlich: Zum einen wird durch die Verwendung des statischen Metamodells – hier in Form der Klasse SomeEntity_ – sicher gestellt, dass das verwendete Attribut der Entity existiert. Zum anderen wird auch hier Typsicherheit erreicht, ebenfalls durch das Metamodell, das für das Attribut name den Typ String “kennt”.

Die Criteria Query erzeugt also zwar einen höheren Schreibaufwand als die herkömmliche Query, bietet dem Entwickler aber eine deutlich höhere Sicherheit, korrekten Code geschrieben zu haben.

Das gezeigte Beispiel setzt allerdings voraus, dass zu jeder Entity-Klasse E eine statische Metamodell-Klasse E_ existiert, die die Metadaten der persistenten Attribute von E enthält. Das statische Metamodel kann man theoretisch manuell erstellen, sinnvoll ist aber m.E. nur die automatische Generierung. Die gelingt durch Annotations-Prozessoren, die seit Java 6 wie Plugins in den Compilerlauf eingeschoben werden können. So kann man bspw. den Hibernate Static Metamodel Generator verwenden. Dies funktioniert auch, wenn nicht Hibernate als JPA-Provider genutzt werden soll, da das Metamodell Provider-übergreifend spezifiziert ist.

Der Einsatz des Hibernate Static Metamodel Generator ist auf der folgende Webseite recht gut erläutert:
http://relation.to/Bloggers/HibernateStaticMetamodelGeneratorAnnotationP…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.

Autor

Diesen Artikel teilen

LinkedIn
Xing

Gibt es noch Fragen?

Fragen beantworten wir sehr gerne! Schreibe uns einfach per Kontaktformular.

Kurse

weitere Blogbeiträge

ng1516titel
Webprogrammierung

Angular 16/17: new control flow

Diese Reihe wirft einen kurzen Blick auf einige Highlights der Angular Versionen 16 und 17. Heute: control flow. Ein fantastisches…

Work Life Balance. Jobs bei Gedoplan

We are looking for you!

Lust bei GEDOPLAN mitzuarbeiten? Wir suchen immer Verstärkung – egal ob Entwickler, Dozent, Trainerberater oder für unser IT-Marketing! Schau doch einfach mal auf unsere Jobseiten! Wir freuen uns auf Dich!

Work Life Balance. Jobs bei Gedoplan

We are looking for you!

Lust bei GEDOPLAN mitzuarbeiten? Wir suchen immer Verstärkung – egal ob Entwickler, Dozent, Trainerberater oder für unser IT-Marketing! Schau doch einfach mal auf unsere Jobseiten! Wir freuen uns auf Dich!