Vor einiger Zeit hat Christian auf seinem Blog das fluent API seiner jRTF-Library vorgestellt, welche dem Benutzer ermöglicht, RTF-Dokumente mit einfachen Sprach-Konstrukten direkt mit Java zu erstellen:

• jRTF: http://www.tutego.de/blog/javainsel/2010/07/jrtf-a-new-library-for-building-rtf-documents/
• Reflection API: http://www.tutego.de/blog/javainsel/2009/02/fluent-interface-based-api-fur-java-reflection-fest-reflect/

DSL (Domain Specific Languages) sind ein spannendes Thema in vielen Bereichen. Für die meisten Zwecke werden sogenannte "externe" DSL’s definiert, also für einen technischen oder fachlichen Bereich spezialisierte Sprachen, welche unabhängig von anderen Sprachen interpretiert oder kompiliert werden. Manchmal gelingt es aber auch, solche spezialisierten Sprachen in einer anderen Sprache zu "internalisieren", wie dies eben mit jRTF gelungen ist. Heute möchte ich eine ähnliche DSL präsentieren, welche ich in jOOQ (Java Object Oriented Querying) eingebaut habe. jOOQ bildet SQL als "interne DSL" in Java ab, so dass Datenbank-Abfragen direkt in Java formuliert werden können. Ein Beispiel:

// Suche alle Bücher, welche in 2011 publiziert wurden
create.select()
      .from(BOOK)
      .where(PUBLISHED_IN.equal(2011))
      .orderBy(TITLE)
      .fetch();

Dabei steht BOOK für eine Tabelle mit den Feldern PUBLISHED_IN und TITLE. Alle diese Objekte werden von jOOQ generiert.

SQL – Grundlagen und Motivation für jOOQ

SQL ist eine deklarative "externe DSL", welche von einem Datenbanksystem in beliebiger Form interpretiert werden kann, um das gewünschte Resultat zu produzieren. So kann eine vereinfachte SELECT-Syntax beispielsweise wie folgt definiert werden:

SELECT [ ALL | DISTINCT [ ON ( ausdruck [, ...] ) ] ] * | 
        ausdruck [ AS ausgabename ] [, ...]
    [ FROM from_element [, ...] ]
    [ WHERE bedingung ]
    [ GROUP BY ausdruck [, ...] ]
    [ HAVING bedingung [, ...] ]
    [ { UNION | INTERSECT | EXCEPT } [ ALL ] select ]
    [ ORDER BY ausdruck [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { anzahl | ALL } ]
    [ OFFSET start ]
    [ FOR UPDATE [ OF tabellenname [, ...] ] ]

Aus dem Postgres-Handbuch:

http://www.postgresql.org/files/documentation/books/pghandbuch/html/sql-select.html

Andere Datenbanken, wie z.B. Oracle, haben noch eine viel komplexere Syntax. Es werden zum Beispiel auch Elemente wie [WITH ..], [CONNECT BY ..], [PIVOT ..], [UNPIVOT ..] und so weiter unterstützt. Auf Details wird hier verzichtet.

Für viele Java-Entwickler ist SQL etwas Externes und wird oft missverstanden, und gemieden. SQL funktioniert grundlegend anders als die meisten prozeduralen oder objekt-orientierten Programmiersprachen. Die Vielfalt von SQL-Dialekten und deren enorm nützlicher Funktionalität wird unter anderem genau deswegen von den führenden Datenbank-Abstraktions-Frameworks hinter massiven Vereinfachungen versteckt. Zum Beispiel hat Hibernate HQL und criteria queries entwickelt, welche nur sehr rudimentäre Abfragen ermöglichen.

jOOQ geht einen anderen Weg und möchte dem SQL-orientierten Entwickler erlauben, sämtliche Syntax-Konstrukte direkt anzuwenden. Dabei macht sich jOOQ die wichtigsten Eigenschaften einer internen DSL zu nutze.

• Die SQL-Abfragen können vom Java Compiler formell auf Syntax und Typsicherheit überprüft werden.
• IDE’s wie Eclipse können mit Auto-Vervollständigung helfen, korrektes SQL zu schreiben
• Unterstützung der gesamten Standard-SQL Syntax, sowie einiger proprietärer Konstrukte. Es gibt keine künstliche Grenze, wie z.B. mit HQL.

Internalisierung einer externen DSL

In diesem Artikel möchte ich aufzeigen, wie eine formell definierte, externe DSL in Java mittels einfacher Regeln "internalisiert" werden kann, und wie dies für SQL in jOOQ gelöst worden ist. Aber zuerst zu den Grundsätzen:

1. Versteckte Implementierung

Der wichtigste Schritt ist der allererste. Eine "interne" DSL ist schwer vorstellbar, ohne das Abstraktionsvermögen von Java’s Schnittstellen zu verwenden. Um eine Implementierung der verschiedenen DSL-Schnittstellen zu konstruieren benötigen wir eine Factory. Je nach Funktionalitätsbedarf kann die Factory statische oder nicht-statische Methoden anbieten. Der Vorteil von statischen Methoden ist die Möglichkeit der Verwendung von static imports, welche den Code noch lesbarer machen. Der Vorteil von nicht-statischen Methoden ist die Möglichkeit, dass die konstruierten Objekte eine Referenz auf die Factory halten können.

2. Schlüsselwörter

Idealerweise wird jedes Schlüsselwort der externen DSL durch eine Java-Methode "internalisiert". Zusammengesetzte Schlüsselwörter (wie z.B. GROUP BY) werden dabei wie in Java üblich durch "Camel Case" zusammengesetzt (also z.B. groupBy). Somit werden die SQL-Schlüsselwörter

SELECT .. FROM .. JOIN .. ON .. WHERE .. GROUP BY

durch die entsprechenden Methoden modelliert:

.select(...).from(...).join(...).on(...).where(...).groupBy(...)

3. Sonderzeichen

Die externe DSL spezifiziert oft Sonderzeichen, wie ( ) || + - und so weiter. Diese Sonderzeichen können in Java nicht abgebildet werden. Andere Sprachen, wie z.B. C++, C# haben mächtigere Mittel um auch Operatoren zu überladen. In Java werden sie am besten einfach ignoriert, oder in extremeren Sonderfällen ausformuliert – also .parentheses() .closingParentheses() .concat() .plus() .minus()

4. Klauseln

Eine Klausel wird meist in einer Form ähnlich dieser Formen hier formuliert:

a) EIN EINZELNES WORT
b) EIN PARAMETRISIERTES WORT parameter
c) EIN WORT [ EIN OPTIONALES WORT ]
d) EIN WORT { EIN WAHLWORT | EIN ANDERES WAHLWORT }
e) EIN WORT [ , EIN WORT ... ]

Die Internalisierung dieser Definitionen erfolgt so:

a) Die Grundklausel

class Factory {
    // Nach EIN EINZELNES WORT geht's nicht mehr weiter.
    // Es können keine weiteren Klauseln angehängt werden
    Schluss einEinzelnesWort();
}

interface Schluss {
    // Hier können grundsätzliche Methoden der DSL deklariert werden
    // z.B. execute(), run(), etc
    void execute();
}

// Anwendung
new Factory().einEinzelnesWort().execute();

b) Eine Klausel mit Parameter, z.B. einem numerischen Parameter

class Factory {
    // Bei "kompatibler" Syntax kann die "Schluss-Schnittstelle"
    // wiederverwendet werden
    Schluss einParametrisiertesWort(int parameter);
}

// Anwendung
new Factory().einParametrisiertesWort(42).execute();

c) Optionale Klauseln

class Factory {
    // Nach EIN WORT können noch weitere Klauseln hinzugefügt werden. 
    // Deswegen wird OptionalerSchritt zurückgegeben
    OptionalerSchritt einWort();
}

// Dadurch, dass OptionalerSchritt von Schluss erbt, können die hier
// deklarierten Methoden (=Schlüsselwörter) übersprungen werden
interface OptionalerSchritt extends Schluss {
    // Danach ist aber trotzdem Schluss
    Schluss einOptionalesWort();
}

// Anwendungen
new Factory().einWort().execute();
new Factory().einWort().einOptionalesWort().execute();

d) Wahl-Klauseln

class Factory {
    // Wie zuvor können nach EIN WORT weitere Klauseln
    // hinzugefügt werden
    WahlSchritt einWort();
}

// Eine Wahl ist nicht optional, es muss eine weitere Klausel
// folgen. Entsprechend erbt die Schnittstelle NICHT
interface WahlSchritt {
    // Es kann gewählt werden zwischen...
    Schluss einWahlwort();
    
    // ... und ...
    Schluss einAnderesWahlwort();
    
    // In jedem Fall gelangt man zum Schluss
}

// Anwendungen
new Factory().einWort().einWahlwort().execute();
new Factory().einWort().einAnderesWahlwort().execute();

e) Wiederholungen

class Factory {
    // Gewisse Klauseln können beliebig oft aneinandergereiht werden.
    WiederholungsSchritt einWort();
}

// Weitere Wiederholungen sind optional. Dies wird auch hier mit Vererbung
// gelöst
interface WiederholungsSchritt extends Schluss {
    // Bei Wiederholung gelangt man zurück zum Ausgangstyp
    WiederholungsSchritt einWort();
}

// Anwendungen
new Factory().einWort().execute();
new Factory().einWort().einWort().execute();
new Factory().einWort().einWort().einWort().execute();

Die genannten Regeln lassen sich beliebig kombinieren und verschachteln, so dass fast alle möglichen Syntaxbäume abbildbar sind. Dadurch kann eine relativ grosse Anzahl Schnittstellen entstehen, was für heutige Compiler und ClassLoader aber kein Problem mehr darstellen sollte.

SQL als interne DSL in jOOQ

Das für jOOQ verwendete fluent API baut auf einer Hierarchie von Schnittstellen auf, welche etwas vereinfacht so definiert ist (die tatsächliche Umsetzung weicht etwas von diesem Beispiel ab):

// Die Factory-Klasse ist der Einstiegspunkt für die DSL.
// Alle Objekte werden von hier konstruiert
class Factory {

    // Es können 1..n Felder selektiert werden
    SelectFromStep select(Field... fields);
}

// Dieser "Schritt" oder diese Klausel der SELECT Syntax
// ist obligatorisch. Man muss also .from() aufrufen
interface SelectFromStep {

    // Es kann von 1..n Tabellen selektiert werden
    SelectJoinStep from(Table... tables);
}

// Dieser "Schritt" der SELECT Syntax ist optional. Er erbt also vom nächsten
// Schritt, falls JOIN's ausgelassen würden
interface SelectJoinStep extends SelectWhereStep {

    // Eine Tabelle kann hinzugefügt werden
    SelectOnStep join(Table table);
}

// Nach einer JOIN-Klausel muss zwingend eine ON- oder USING-Klausel folgen.
// Danach ist eine weitere JOIN-Klausel möglich.
interface SelectOnStep {
    SelectJoinStep on(Condition condition);
    SelectJoinStep using(Field... fields);
}

// Auch die WHERE-Klausel ist optional.
interface SelectWhereStep extends SelectOrderByStep {

    // Der Einfachheit halber werden GROUP BY, HAVING Klauseln übersprungen.
    SelectOrderByStep where(Condition condition);
}

// Auch die ORDER BY-Klausel ist optional.
interface SelectOrderByStep extends SelectFinalStep {
    
    // Der Einfachheit halber wird hier abgebrochen
    SelectFinalStep orderBy(SortField... fields);
}

Und so weiter. Die Implementierung all dieser Schnittstellen übernimmt eine einzige, nur der Factory bekannte Klasse, welche sämtliche Methoden-Aufrufe registriert und am Schluss eine passende SQL-Abfrage als String ausführt. Mehr Details hierfür gibt’s hier:

https://sourceforge.net/apps/trac/jooq/wiki/Manual/DSL/SELECT

Interessant ist auch die Frage, wie zusammengesetzte Elemente wie Condition und SortField zustande kommen. Diese werden durch von der SELECT-Syntax unabhängige DSL’s erstellt. So bietet zum Beispiel der Typ Field folgende DSL-Methoden an:

interface Field {
    
    // Erstellen von Conditions
    Condition equal(Field field);
    Condition equal(Object value);
    Condition notEqual(Field field);
    Condition notEqual(Object value);
    // [...] und noch viele mehr
    
    // Erstellen von spezialisierten Feldern für die ORDER BY Klausel
    SortField asc();
    SortField desc();
}

Diese Typen wiederum erlauben weitere DSL-Schritte:

interface Condition {

    // Zusammensetzen von Conditions
    Condition and(Condition condition);
    Condition andNot(Condition condition);
    Condition or(Condition condition);
    Condition orNot(Condition condition);
    
    // Negieren von Conditions
    Condition not();
}

interface SortField {

    // Hinzufügen von weiteren Schlüsselwörtern
    SortField nullsFirst();
    SortField nullsLast();
}

Grenzen von internen DSL’s

Mit jOOQ ist es bereits möglich, sehr komplexe SQL-Abfragen in Java zu formulieren. Dies beinhaltet unter anderem

• Verschachtelte Abfragen
• Stored Procedures und Functions
• Komplexe JOINs
• Rekursives SQL (CONNECT BY, bald auch Common Table Expressions)
• Window/Ranking Functions
• Bald auch Oracle’s PIVOT/UNPIVOT Syntax

Trotzdem kann eine interne DSL nie die Mächtigkeit ihrer abgebildeten externen DSL erreichen. Die grössten Limitierungen in jOOQ sind zum Beispiel

1. Aliasing

In SQL können Tabellen und Felder einfach mit Namen versehen werden, zum Beispiel um Kinder-Elemente mit ihren Eltern-Elementen zu verknüpfen:

SELECT *
FROM my_table a, my_table b
WHERE a.id = b.parent

Dies ist in jOOQ etwas umständlicher:

Table<?> a = MY_TABLE.as("a");
Table<?> b = MY_TABLE.as("b");

create.select()
      .from(a, b)
      .where(a.getField(ID).equal(b.getField(PARENT)));

2. Grenzen der Syntax

Wie bereits erwähnt können SQL-spezifische Sonderzeichen nicht berücksichtigt werden, auch wenn diese sinnvoll für die Lesbarkeit wären. Umgekehrt fügt jeder Methodenaufruf() ein weiteres Klammern-Paar hinzu. Dies kann schon Lisp-ähnliche Zustände erreichen 🙂

Man beachte die vier Klammern am Schluss:

create.select()
      .from(BOOK)
      .where(Book.AUTHOR_ID.in(create.select(Author.ID)
                                     .from(AUTHOR)
                                     .where(Author.BORN.equal(1920))));

3. Nur die Syntax kann validiert werden, nicht die Semantik

In SQL ist es zum Beispiel nicht möglich, bei einer gruppierten Abfrage ein Feld zu selektieren, welches nicht auch in der GROUP BY Klausel Auftritt. Dies ist zum Beispiel nicht korrekt:

SELECT id
FROM book
GROUP BY title

jOOQ kann dies nicht zur Kompilierzeit überprüfen, und somit ist folgende Abfrage (in Java) möglich:

create.select(ID)
      .from(BOOK)
      .groupBy(TITLE)

Fazit

jOOQ ist ein sehr aktives Projekt und wie jRTF ein gutes Beispiel für den Nutzen eines fluent API in der modernen Java-Welt. Mit jOOQ können SQL-bewandte Programmierer wie auch SQL-Anfänger von der Typsicherheit einer internen DSL, sowie vom Funktionalitätsumfang ihrer Datenbank vollumfänglich profitieren, und dies ohne relevanten Performance-Overhead.

Weitere Details auf http://www.jooq.org

Und auf der User-Group: http://groups.google.com/group/jooq-user

Vielen Dank auch an Christian, dafür dass er mir die Möglichkeit eines Gast-Artikels gegeben hat.

Lukas Eder (lukas.eder@gmail.com)

Ähnliche Beiträge

• Erste Libs springen auf Java 8 auf
• Inselraus: Selektionen einer Tabelle
• Inselraus: Tabellenkopf von Swing-Tabellen
• Update von CsvJdbc, einem JDBC-Treiber für CSV-Dateien
• EJB 2.x und EJB 3.0 vereinen