Interview mit Simon Martinelli

Query Language Result Mapper 1.0: Persistenz mit JPA und nativen SQL Queries

Hartmut Schlosser

Unter dem Namen „Query Language Result Mapper“ (QLRM) steht ein neues Projekt auf GitHub zur Verfügung, mit dem sich eine Lücke des Java Persistence API (JPA) schließen lässt. JPA sieht nämlich keine Constructor Expression für native SQL Queries vor. Wir sprachen mit Projektentwickler Simon Martinelli über Funktionsweise und Entwicklungsstand des Projektes.

JAXenter: Du hast mit dem „Query Language Result Mapper“ (QLRM) ein neues Projekt an den Start gebracht. Kannst du das Projekt selbst kurz vorstellen?

Simon Martinelli: JPA bietet seit der Version 1.0 eine Constructor Expression, mit der man POJOs, in der Regel Transferobjekte, direkt aus JPQL befüllen kann.
In der Praxis kommt es häufig vor, dass aus Performance-Gründen sogenannte native Queries verwendet werden, also reine SQL Statements. Leider fehlt in JPA die Möglichkeit, die Constructor Expression mit nativen Queries zu vewenden.

Mit JPA 2.1 ist mit dem Constructor Mapping die Möglichkeit geschaffen worden, SQL Statements auf POJOs zu mappen. Leider ist diese Variante nicht so elegant wie die Constructor Expression, da es ein explizites Mapping braucht. Aus diesem Grund habe ich das Projekt QLRM ins Leben gerufen. QLRM funktioniert übrigens auch mit reinem JDBC.

Um das Erstellen der TO-Klassen auch noch zu vereinfachen, wurde ein ClassGenerator implementiert, der aus Tabellen oder SELECT Statements TO-Klassen mit dem passenden Konstruktor erzeugt.

JAXenter: Wie funktioniert der Query Language Result Mapper?

Simon Martinelli: Der QLRM bietet statische Methoden, um aus JPA Queries oder JDBC ResultSets Transferobjekte zu erstellen. Es muss lediglich angegeben werden, welche Klasse für die Instanzierung verwendet werden soll, beispielsweise JpaSqlResultMapper.list(q, EmployeeTO.class);

Intern nutzt QLRM Reflection für die Erzeugung der Objekte. Der ClassGenerator verwendet via JDBC die Metadaten der Datenbank, um daraus passende Klassen zu generieren.

JAXenter: Kannst du einen Use Case beschreiben, in dem der Query Language Result Mapper gute Dienste leisten kann?

Simon Martinelli: QLRM kann immer dann zum Einsatz kommen, wenn man SQL für die Abfragen verwenden will bzw. muss aber als Resultat gerne Objekte, und nicht wie bei JPA eine Liste von Object[] oder bei JDBC ein ResultSet, möchte. Dabei spielt es wie gesagt keine Rolle ob man JPA oder JDBC direkt verwenden will.

JAXenter: Wie ist der aktuelle Entwicklungsstand?

Simon Martinelli: Die Version ist voll funktionsfähig und zum Einsatz bereit. Verbesserungsvorschläge werden gerne entgegengenommen.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.