iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit Java und SQL zu arbeiten
2 gefällt mir7,445 aufrufe
Die Ausgabe von 'Java aktuell' 02-2015 thematisiert die Entwicklungen rund um Java, besonders in Bezug auf Datenbankzugriffe. Es wird die Bedeutung von JDBC und seiner Entwicklung über die Jahre hervorgehoben, sowie die Herausforderungen bei der Implementierung von dynamischem SQL. Darüber hinaus wird jOOQ als moderne, SQL-orientierte API vorgestellt, die Entwicklern ermöglicht, SQL-Anfragen in Java einfacher und typsicher zu gestalten.
iJUG Java Aktuell [Februar 2015] Lukas Eder - jOOQ - ein alternativer Weg mit Java und SQL zu arbeiten
- 1. D:4,90EUR A:5,60EUR CH:9,80CHF Benelux:5,80EUR ISSN2191-6977 Javaaktuell Javaaktuell 02-2015 | Sommer | www. ijug.eu Praxis. Wissen. Networking. Das Magazin für Entwickler Aus der Community — für die Community 419197830490302 iJUG Verbund Programmierung JavaScript für Java-Entwickler Cloud Computing Software-Architekturen in wolkigen Zeiten JavaServer Faces Interview mit Spec Lead Ed Burns Applikationsserver JBoss vs. WebLogic Server
- 2. 4 | Inhalt Der Autor ist ein sehr großer Fan von Java, aber auch von C#. Er stellt einige interessante Seiten von C# vor In Xtend geschriebener Code ist meist kom- pakter und eleganter als sein Java-Äquivalent 27 5 Das Java-Tagebuch Andreas Badelt 8 Software-Architekturen in wolkigen Zeiten Agim Emruli 12 „Ich glaube, dass die Expression Lan- guage der heimliche Held der gesam- ten Web-Ebene von Java EE ist …“ Interview mit Ed Burns 14 Einstieg in die Liferay-Portal- EntwicklungunterVerwendungvonJSF Frank Schlinkheider & Wilhelm Dück 19 JavaScript für Java-Entwickler Niko Köbler 21 Besser Java programmieren mit Xtend Moritz Eysholdt 27 Ich liebe Java und ich liebe C# Rolf Borst 30 Gestensteuerung und die nächste Welle der 3D-Kameras Martin Förtsch & Thomas Endres 35 Microservices und die Jagd nach mehr Konversion – das Heilmittel für er- krankte IT-Architekturen? Bernd Zuther, codecentric AG 41 Alles klar? Von wegen! Von Glücksrädern, Bibliothekaren und schwierigen Fragen Dr. Karl Kollischan 44 Greenfoot: Einstieg in die objektorien- tierte Programmierung Dennis Nolte 47 jOOQ – ein alternativer Weg, mit Java und SQL zu arbeiten Lukas Eder 53 JBoss vs. WebLogic Server – ein Duell auf Augenhöhe? Manfred Huber 58 PDF-Dokumente automatisiert testen Carsten Siedentop 62 Unbekannte Kostbarkeiten des SDK Heute: Bestimmung des Aufrufers Bernd Müller, Ostfalia 64 Einstieg in Eclipse Gelesen von Daniel Grycman 64 Java – Der Grundkurs Gelesen von Oliver B. Fischer 65 Android-Apps entwickeln Gelesen von Ulrich Cech Die Korrektheit erzeugter PDF-Dokumente überprüfen – nicht manuell, sondern automatisiert 58 21
- 3. | 47 www.ijug.eu iii iiiiii iii Java aktuell 2-2015 Java feiert in diesem Jahr seinen 20. Ge- burtstag. Mit der JDK 1.1 wurde im Jahr 1997 das erste Mal Java Database Connec- tivity (JDBC) mitgeliefert und auch heute noch mit der JDK 1.8 stellt JDBC die Stan- dardschnittstelle zwischen Java und SQL beziehungsweise NoSQL-Datenbanken dar. JDBC wurde sehr stark von Microsoft Open Database Connectivity (ODBC) inspi- riert – ein sehr generisches und populäres Low-Level-API, das zu einer Zeit entwickelt wurde, als SQL sich selber erst gerade mit SQL-86, SQL-89 und SQL-92 als ISO/IEC Standard gegenüber alternativen Abfrage sprachen durchgesetzt hatte. SQL hat seitdem sehr viele Weiterent- wicklungen gesehen; JDBC ist hingegen im- mer noch gleich geblieben. Auch nach all den Jahren schreibt man immer noch Code wie in Listing 1, in dem sich sechs typische Bugs eingeschlichen haben. Diese sind: • Zeile 04 Syntaxfehler, wenn „isAccount == false“ wegen eines fehlenden Leerzeichens vor dem „FROM“-Schlüsselwort • Zeile 07 Syntaxfehler und SQL-Injection sind mög- lich, falls die „type“-Variable unkontrol- lierte Benutzereingabewerte darstellt • Zeile 08 Es wird der falsche Bind-Index verwen- det, falls „isAccount == false“, da die Vari- able aus Zeile 03 dann nicht existiert • Zeile 14 DerSpaltennamestimmtsonicht,dadieSpal- teinZeile02auf„TXT“umbenanntwurde • Zeile 15 Die „Clob“-Ressource wird nicht expli- zit mittels „Clob.free()“ freigegeben. Die- se Änderung in JDBC 4.0 ist nur wenigen Programmierern bekannt und kann zu exzessivem Memory-Verbrauch führen. • Zeile 18 Die Ressourcen werden nicht sachgemäß geschlossen, was ebenfalls zu Ressour- cenlecks führen kann. Dieses Problem wurde glücklicherweise mit Java 7 für die meisten Fälle adressiert. Diese sechs Fehler entstehen sehr oft, wenn man mit JDBC dynamisches SQL implemen- tiert. Jeder Entwickler, der Wartungsarbei- ten an einem solchen Statement ausführen muss, riskiert mit jeder Änderung weitere Fehler einzuführen. jOOQ – ein alternativer Weg, mit Java und SQL zu arbeiten Lukas Eder, Data Geekery GmbH InJavagibteskeinStandard-API,dasdieAusdrucksstärkeundMächtigkeitvonSQLdirektunterstützt.AlleAufmerk- samkeitistaufobjekt-relationalesMappingundanderehöhereAbstraktionslevelgerichtet,beispielsweiseOQL, HQL,JPQL,CriteriaQuery.jOOQisteindual-lizenziertesOpen-Source-Produkt,dasdieseLückefüllt.Esimplementiert SQLalstypsicheredomänen-spezifischeSprachedirektinJavaundisteineguteWahlfürJava-Applikationen,in denenSQLundherstellerspezifischeDatenbankfunktionalitätwichtigsind.Eszeigt,wieeinemodernedomänen- spezifischeSprachedieEntwicklerproduktivitätstarkerhöhenkann,indemSQLdirektinJavaeingebettetist. 01: PreparedStatement stmt = connection.prepareStatement( 02: "SELECT p.text txt" + 03: (isAccount ? ", NVL(a.type, ?) " : "") + 04: "FROM products p " + 05: (isAccount ? " INNER JOIN accounts a USING (prod_id) " : "") + 06: " WHERE p.cust_id = ? AND p.value < ?" + 07: (isAccount ? " AND a.type LIKE '%" + type + "%'" : ""); 08: stmt.setInt(1, defaultType); 09: stmt.setInt(2, custID); 10: stmt.setBigDecimal(3, BigDecimal.ZERO); 11: ResultSet rs = stmt.executeQuery(); 12: 13: while (rs.next()) { 14: Clob clob = rs.getClob("TEXT"); 15: System.out.println(clob.getSubString(1, (int) clob.length()); 16: } 17: 18: rs.close(); 19: stmt.close(); Listing 1
- 4. 48 | SQL SUM(t.amount) OVER ( PARTITION BY t.account_id ORDER BY t.value_date DESC, t.id DESC ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING ) Listing 4 | ID | VALUE_DATE | AMOUNT | BALANCE | |------|------------|---------|------------| | 9997 | 2014-03-18 | -(99.17)| +19985.81 | | 9981 | 2014-03-16 | -(71.44)| 19886.64 | | 9979 | 2014-03-16 |-(-94.60)| 19815.20 | | 9977 | 2014-03-16 | -6.96 | =19909.80 | | 9971 | 2014-03-15 | -65.95 | 19916.76 | Listing 5 Die Geschichte von Java und SQL Die logische Weiterentwicklung von Daten- bank-Zugriffen in Java war Enterprise Java- Beans (EJB), später hat sich dann auch Java Persistence API (JPA) gegenüber der Kon- kurrenz (beispielsweise Java Data Objects) durchgesetzt. Der wichtigste Fortschritt von JPA gegenüber JDBC besteht darin, dass nicht mehr SQL geschrieben wird, sondern direkt ein Modell des Objektgraphen erstellt wird, das in etwa dem darunterliegenden re- lationalen Modell entspricht. Mit diesem Ansatz kann der Objektgraph direkt in Java-Objekten materialisiert wer- den, ohne lange über die dafür benötigten SQL-Abfragen nachdenken zu müssen, was sich vor allem in schreibintensiven Appli- kationen bemerkbar macht, da weder die korrekte Reihenfolge, noch die Natur der Befehle („INSERT“ oder „UPDATE“?) auspro- grammiert werden muss. Der Nachteil von diesem Ansatz wird oft fälschlicherweise als objekt-relationaler „Impedanz Mismatch“ bezeichnet, denn es handelt sich viel eher um einen Mismatch zwischen Objektorientierung und SQL selbst. Häufig will man sich nämlich als Entwickler nicht mit dem Objektgraphen auseinander- setzen, wie beispielsweise Gavin King, der ursprüngliche Entwickler von Hibernate, sagt (siehe Abbildung 1). SQL entwickelt sich in eine andere Richtung als JPA SQL hat sich in vielen weiteren Versionen des Standards weiterentwickelt: • SQL-1999 Common Table Expressions, Grouping Sets, user-defined types, Boolean types • SQL-2003 Fensterfunktionen, XML-Unterstützung, Sequenzen und Identities, MERGE-Befehl • SQL-2008 Partitionierte JOINs, Blättern mit OFFSET • SQL-2011 Versionierte Tabellen, Zeitperioden Neben diesen größeren Weiterentwick- lungen gibt es noch viele kleinere Funkti- onalitäten, insbesondere aus dem OLAP- Bereich, die nur sehr wenig mit JPA und mit Objektgraph-Persistenz zu tun haben. Diese Funktionalitäten sind aber ungemein mäch- tig, und können zu sehr viel einfacheren und schnelleren Programmen führen. Der RAM-Preis fällt und fällt. Es macht deshalb immer mehr Sinn, den verteilten Systemen und NoSQL-Trends aus den letzten fünf Jahren entgegenzuwirken und stattdes- sen auf Multi-Core-Prozessor-Architekturen komplette Datenbanken in den Speicher zu laden und Abfragen via SQL oder via gespei- cherte Prozeduren sehr nahe an den Daten selbst auszuführen. Damit spart man sich sehr schnell einigen vom CAP-Theorem ver- ursachten Ärger. Ein Beispiel mit Fenster- Funktionen Am besten ist die Mächtigkeit von moder- nem SQL am Beispiel von Fenster-Funkti- onen ersichtlich, ein SQL-Feature, das ins Vokabular eines jeden Java/SQL Entwick- lers gehört. Listing 2 zeigt das Beispiel einer Datenstruktur, wobei die Spalte BALANCE eine berechnete Spalte sein soll. Es handelt sich um einen klassischen laufenden Kon- tostand ( „running total“), der beispielswei- | ID | VALUE_DATE | AMOUNT | BALANCE | |------|------------|--------|------------| | 9997 | 2014-03-18 | 99.17 | 19985.81 | | 9981 | 2014-03-16 | 71.44 | 19886.64 | | 9979 | 2014-03-16 | -94.60 | 19815.20 | | 9977 | 2014-03-16 | -6.96 | 19909.80 | | 9971 | 2014-03-15 | -65.95 | 19916.76 | Listing 2 | ID | VALUE_DATE | AMOUNT | BALANCE | |------|------------|--------|------------| | 9997 | 2014-03-18 | 99.17 | 19985.81 | | 9981 | 2014-03-16 | +71.44 | =19886.64 | n | 9979 | 2014-03-16 | -94.60 | +19815.20 | n + 1 | 9977 | 2014-03-16 | -6.96 | 19909.80 | | 9971 | 2014-03-15 | -65.95 | 19916.76 | BALANCE(ROWn) = BALANCE(ROWn+1) + AMOUNT(ROWn) BALANCE(ROWn+1) = BALANCE(ROWn) – AMOUNT(ROWn) Listing 3 Abbildung 1: Gavin King auf Google +
- 5. | 49 www.ijug.eu iii iiiiii iii Java aktuell 2-2015 se in Microsoft Excel ganz einfach gemäß einer Formel berechnet werden könnte (sie- he Listing 3). Natürlich könnte man diesen laufenden Kontostand in Java berechnen, doch sehr viel einfacher geht es eben mit Fenster- Funktionen, zum Beispiel mit der Summe (siehe Listing 4). Diese Summe berechnet für jede Reihe aus der „SELECT“-Klausel eine Summe aller Werte, die folgende Bedingung erfüllen: • In derselben Partition (= Gruppe) liegen, wie die aktuelle Reihe. Sie müssen den- selben Wert für die Kontonummer haben („PARITION BY ...“) • Absteigend sortiert nach Valuta und Bu- chungs-ID („ORDER BY ...“) • Über der aktuellen Reihe liegen („ROWS BETWEEN ... AND ...“) Viel einfacher als mit Text lässt sich die- ses Beispiel visuell veranschaulichen. Jeder „BALANCE“-Wert kann berechnet werden als die Differenz zwischen dem neuesten „BALANCE“-Wert und der Summe aller Be- tragswerte, die über dem zu berechnenden „BALANCE“-Wert liegen (siehe Listing 5). Hinweis: Fenster-Funktionen sind in al- len kommerziellen Datenbanken sowie in PostgreSQL und bald auch in Firebird 3.0 unterstützt. Was hat das mit jOOQ zu tun? jOOQ ist ein Java-API, das sich im stark SQL-orientierten Umfeld wachsender Be- liebtheit erfreut. Die Idee hinter jOOQ ist ganz einfach. Vorausgesetzt, dass SQL als Sprache in einer Software strategisch wichtig ist, dann möchten Entwickler mög- lichst reibungslos SQL-Befehle von belie- biger Komplexität schreiben können. Mit jOOQ können sie dies direkt und typsicher in Java machen. Angenommen der Ent- wickler möchte die Umfrage-Ergebnisse einer fast repräsentativen Umfrage zum beliebtesten Datenbank-API auswerten, um zu dem Resultat zu kommen, das in Listing 6 zu sehen ist. Die Spalten „RANK“ und „PERCENT“ sollen wiederum berech- net werden. Dafür wird sich der Entwickler eine SQL-Abfrage überlegen (siehe Listing 7). Er kann diese in Java fast „1:1“ identisch schreiben (siehe Listing 8) oder noch besser in Scala (siehe Listing 9). Die Beispiele sind tatsächlich Java- oder Scala-Code und der jOOQ -Compiler kann auch etliche syntak- tische Regeln überprüfen. jOOQ ist eine interne Domä- nen-spezifische Sprache SQL selbst kann ja bereits als eine Domain- specific Language (DSL) betrachtet werden. Generell unterscheidet man zwischen ex- ternen und internen DSLs. SQL ist für Java- Entwickler eine externe DSL, da die Sprache unabhängig von Java extern interpretiert und ausgeführt wird. Viele DSLs werden aber als intern implementiert, sie werden also direkt in Java(odereineranderenHauptsprache)umge- setzt. Ein Beispiel für eine solche interne DSL sind verschiedene Mocking-Frameworks (wie Hamcrest) für Unit-Testing. Im Grunde könn- ten auch die mathematischen Operationen auf „BigInteger“ und „BigDecimal“ als interne DSLs betrachtet werden. Abbildung 2 zeigt, dass fast alle Sprachen auf eine Meta-Grammatik zurückgeführt werden können. Eine solche Grammatik lässt sich relativ trivial als interne | TEXT | VOTES | RANK | PERCENT | |-------------|-------|------------|---------| | jOOQ | 1383 | 1 | 32 % | | Hibernate | 1029 | 2 | 23 % | | EclipseLink | 881 | 3 | 20 % | | JDBC | 533 | 4 | 12 % | | Spring JDBC | 451 | 5 | 10 % | Listing 6 Abbildung 2: Meta-Grammatik SELECT p.text, p.votes, DENSE_RANK() OVER (ORDER BY p.votes DESC) AS "rank", LPAD( (p.votes * 100 / SUM(p.votes) OVER ()) || ' %', 4, ' ' ) AS "percent" FROM poll_options p WHERE p.poll_id = 12 ORDER BY p.votes DESC Listing 7 Listing 8 select (p.TEXT, p.VOTES, denseRank().over().orderBy(p.VOTES.desc()).as("rank2), lpad( p.VOTES.mul(100).div(sum(p.VOTES).over()).concat(" %"), 4, " " ).as("percent")) .from (POLL_OPTIONS.as("p")) .where (p.POLL_ID.eq(12)) .orderBy(p.VOTES.desc());
- 6. 50 | SQL SELECT customer.first_name, customer.last_name FROM customer UNION SELECT staff.first_name, staff.last_name FROM staff select (CUSTOMER.FIRST_NAME, CUSTOMER.LAST_NAME) .from (CUSTOMER) .union ( select (STAFF.FIRST_NAME, STAFF.LAST_NAME) .from (STAFF) ) select (CUSTOMER.FIRST_NAME, CUSTOMER.LAST_NAME) .from (CUSTOMER) .union ( // ^^^^^ hier entsteht ein Fehler. Der Parameter ist nicht vom Typ // Select<? extends Record2<String, String>>, sondern vom Typ // Select<Record1<String>> select (STAFF.FIRST_NAME) .from (STAFF) Listing 13 Listing 12 Listing 11 DSL implementieren (siehe Listing 10). jOOQ geht hier noch einiges weiter und verwendet auch andere Java-Sprachtools wie Varargs, Methoden-Überladen und sehr viele Generics. Starke Typsicherheit Wer viel in SQL oder gar in PL/SQL, in Trans act-SQL oder in anderen prozeduralen Dia- lekten programmiert, dem ist geläufig, dass SQL eine sehr typsichere Sprache ist. Mittels „SELECT“-Befehlen lassen sich Ad-hoc-Ta- bellenausdrücke erstellen, deren Reihentyp sehr wohldefiniert ist. Moderne Sprachen wie Scala oder C# ken- nen ebenfalls generisch typisierte Tupel, also namenloseDatenstrukturenmit„1-n“-Feldern unterschiedlichen Typs. Das Beispiel in Listing 11veranschaulichtdieseTypsicherheitanhand einer „UNION“-Klausel und vereint zwei Tupel- Mengen in einer einzigen Menge. Listing 12 zeigt, wie der Befehl in jOOQ aussieht. Dabei enthält der Typ, den der „select()“- Aufruf zurückgibt, bereits alle benötigten Typ- Informationen, um später bei „union()“ den entsprechenden Typ-Check zu machen: Ein Typ, der mit „Record2<String, String>“ para- metrisiert ist. Die „select()“-Methode erwar- tet nun einen Parameter vom Typ „Select<? extends Record2<String, String>>“. Dies führt dazu, dass der Java-Compiler – im Unwissen was er gerade verarbeitet – folgende SQL-Be- fehle mit Fehlermeldungen verwirft: „Falsche Anzahl von Feldern in der SELECT-Klausel“ (siehe Listing 13) und „Falsche Typen der Felder in der SELECT-Klausel“ (siehe Listing 14). Typsicheres „IN“-Prädikat Die Typsicherheit kann in allem möglichen SQL-Befehlen oder Klauseln zur Anwen- dung kommen, auch bei einem „IN“-Prä- dikat (siehe Listing 15). In diesem Beispiel erwartet die „in()“-Methode wiederum ei- nen Parameter vom Typ „select<? extends Record1<String>>“, sodass die Anwendung einen Fehler bei der Kompilierung generiert (siehe Listing 16). Typsicherer „INSERT“-Befehl Auch der „INSERT“-Befehl ist insofern typ- sicher, dass die Anzahl und die Typen der Werte in der „INSERT“-Liste der Anzahl und den Typen der Werte in der „VALUES“-Klausel entsprechen müssen (siehe Listing 17). Listing 18 zeigt den Befehl, der nicht kompiliert wird. Datenbank zuerst Eingangs wurde die Geschichte von Java und SQL erörtert. Dabei hat sich gezeigt, dass JPA select (p.TEXT, p.VOTES, denseRank() over() orderBy(p.VOTES desc) as "rank", lpad( (p.VOTES * 100) / (sum(p.VOTES) over()) || " %", 4, " " ) as "percent") from (POLL_OPTIONS as "p") where (p.POLL_ID === 12) orderBy (p.VOTES desc) Listing 9 // Einstiegsschnittstelle für die DSL, könnte auch über statische Methoden // implementiert werden interface Start { End singleWord(); End parameterisedWord(String parameter); Intermediate1 word1(); Intermediate2 word2(); Intermediate3 word3(); } // Ausstiegsschnittstelle, könnte auch Methoden wie execute() enthalten interface End { void end(); } // Zwischenschritt, welcher die Ausstiegsschnittstelle erweitert, sowie auch // von optionalWord() zurückgibt. Dadurch wird dieser Schritt optional interface Intermediate1 extends End { End optionalWord(); } // Zwischenschritt, der mehrere Möglichkeiten anbietet interface Intermediate2 { End wordChoiceA(); End wordChoiceB(); } // Zwischenschritt, der sich selber zurückgibt beim Aufruf auf word3(), was // Wiederholungen ermöglicht. Wiederholungen können jederzeit beendet werden // da die Ausstiegsschnittstelle implementiert wird. interface Intermediate3 extends End { Intermediate3 word3(); } Listing 10
- 7. | 51 www.ijug.eu iii iiiiii iii Java aktuell 2-2015 select (CUSTOMER.FIRST_NAME, CUSTOMER.LAST_NAME) .from (CUSTOMER) .union ( // ^^^^^ hier entsteht ein Fehler. Der Parameter ist nicht vom Typ // Select<? extends Record2<String, String>>, sondern vom Typ // Select<Record2<String, Date>> select (STAFF.FIRST_NAME, STAFF.DATE_OF_BIRTH) .from (STAFF) ) Listing 14 Listing 15 Listing 16 select () .from (CUSTOMER) .where (CUSTOMER.FIRST_NAME.in( select (STAFF.FIRST_NAME).from (STAFF) )) select () .from (CUSTOMER) .where (CUSTOMER.FIRST_NAME.in( // hier entsteht ein Fehler ^^^. Der Parameter ist nicht vom Typ // Select<? extends Record1<String>>, sondern vom Typ // Select<Record2<String, String>> select (STAFF.FIRST_NAME, STAFF.LAST_NAME).from (STAFF) )) einen ganz anderen Weg gegangen ist als SQL – einen Java-zentrischen Weg. Ein typi- scher Anwendungsfall für JPA entsteht, wenn die Java-Applikation im Vordergrund steht und die Persistenz-Schicht im Hintergrund. Die Java-Applikation könnte auch in ganz an- dere Persistenz-Anbieter schreiben wie No SQL-Datenbanken, File-Systeme, LDAP etc. In vielen komplexeren und langlebigen System-Architekturen steht aber die Daten- bank im Mittelpunkt, und es gibt zum Beispiel verschiedene Applikationen (Java wie Nicht- Java), die auf eine solche Datenbank zugrei- fen. So. könnten diese Applikationen Web- Applikationen, Administrations-Konsolen, ETL-Skripte, Monitoring-Tools etc. sein. Komplexe Systeme entwickeln sich oft um die Datenbank herum, da die Daten alle anderen System-Teilnehmer überleben. Noch heute werden COBOL- oder Delphi- Applikationen durch Java-Applikationen ersetzt – die Datenbank aber bleibt. In diesen Szenarien eignet sich SQL und da- mit jOOQ besonders gut. Entsprechend wurde jOOQ mit einer „Datenbank zuerst“- Philosophie entwickelt, die sich neben den bisher aufgeführten SQL-Funktionalitäten auch noch zeigt. Der Code-Generator Die hier gezeigten Beispiele verwenden ge- nerierten Quellcode, der von jOOQ aus den Meta-Informationen der Datenbank be- reitgestellt wird. So entsteht also für jede Tabelle eine Klasse und für jede Spalte ein Attribut in der Klasse. Ein vereinfachtes Beispiel würde wie in Listing 19 aussehen. Der Code Generator kann dann fix im Ent- wicklungsprozess eingebunden und zum Beispiel nach einer Flyway-Datenbank-Mig- ration sofort angestoßen werden. Die gene- rierten Meta-Informationen gewährleisten, dass jede Änderung am Datenbank-Schema sich sofort in Compiler-Fehler niederschlägt, etwa bei einer Umbenennung oder Entfer- nung einer Spalte. Die Performance Je mehr sich die Datenbank in den Mittel- punkt einer Architektur verschiebt, desto wichtiger wird der Faktor „Performance“ auf dieser Datenbank. Mit JPA ist es praktisch unmöglich, die generierten SQL-Befehle zu optimieren – nicht zuletzt wegen der „N+1“- Problematik, die sich beim Navigieren des Objekt-Graphen nicht verhindern lässt. SQL – und damit jOOQ – beeinflussen die Per- formance sehr feingranular. Listing 17 Listing 18 insertInto (CUSTOMER, CUSTOMER.FIRST_NAME, CUSTOMER.LAST_NAME) .values ( ”John” , ”Doe” ) insertInto (CUSTOMER, CUSTOMER.FIRST_NAME, CUSTOMER.last_name) .values ( ”John” ) // ^^^^^^^^^ Falsche Anzahl an Parametern. Erwartet wurden: String, String // Alle Tabellenreferenzen werden hier aufgelistet: class Tables { Customers CUSTOMER = new Customer(); Staff STAFF = new Staff(); } // Alle Tabellen werden durch individuelle Klassen repräsentiert, // jeweils mit Spalten drin: class Customer { final Field<String> FIRST_NAME = ... final Field<String> LAST_NAME = ... } Listing 19 // Der CustomerRecord wurde ebenfalls vom Code Generator generiert: CustomerRecord customer = DSL.using(configuration) .selectFrom(CUSTOMER) .where(CUSTOMER.ID.eq(3)) .fetchOne(); // Ändern und speichern des Kundenrecords. customer.setAddress(newAddress); customer.store(); Listing 20
- 8. 52 | SQL -- DB2 (mit OFFSET), SQL Server 2008 (mit OFFSET) SELECT * FROM ( SELECT BOOK.*, ROW_NUMBER() OVER (ORDER BY ID ASC) AS RN FROM BOOK ) AS X WHERE RN > 1 AND RN <= 3 -- DB2 (mit OFFSET), SQL Server 2008 (mit OFFSET) SELECT * FROM ( SELECT DISTINCT BOOK.ID, BOOK.TITLE DENSE_RANK() OVER (ORDER BY ID ASC, TITLE ASC) AS RN FROM BOOK ) AS X WHERE RN > 1 AND RN <= 3 -- Oracle 11g und älter SELECT * FROM ( SELECT b.*, ROWNUM RN FROM ( SELECT * FROM BOOK ORDER BY ID ASC ) b WHERE ROWNUM <= 3 ) WHERE RN > 1 Listing 22 Lukas Eder ist der Gründer und Geschäftsführer der Data Geekery GmbH, die Firma hinter jOOQ. Er ist ak- tiv an der Entwicklung von jOOQ beteiligt und berät Kunden zu ver- schiedenen Themen an der Java- und SQL-Schnittstelle sowie auch bei der PL/SQL-Entwicklung. http://ja.ijug.eu/15/2/12 Lukas Eder lukas.eder@datageekery.com möchten, sodass sich der Java-Code genau- so wie SQL-Code anfühlt. Gleichzeitig wur- de jOOQ so konzipiert, dass möglichst viel Typsicherheit bereits bei der Kompilierung erstellt werden kann, sowohl in Java wie auch in Scala, Groovy etc., was die Fehler- anfälligkeit reduziert und somit die Qualität und Produktivität erhöht.. jOOQ ist frei verfügbar unter der Apache Lizenz 2.0 in Verwendung mit Open-Source- Datenbanken oder unter einer kommerziel- len Lizenz in Verwendung mit kommerziel- len Datenbanken. Weiterführende Informationen 1. Die jOOQ-Dokumentationsseite: http://www. jooq.org/learn 2. Java Fluent API Designer Crash-Kurs: http://blog. jooq.org/2012/01/05/the-java-fluent-api-de- signer-crash-course/ 3. Ein Webinar mit Arun Gupta von Red Hat über jOOQ und JavaEE: https://www.youtube.com/ watch?v=ZQ2Y5Z0ju3c 4. Eine Präsentation über jOOQ an der GeeCON Krakau: http://vimeo.com/99526433 -- MySQL, H2, HSQLDB, Postgres und SQLite SELECT * FROM BOOK LIMIT 1 OFFSET 2 -- CUBRID unterstützt eine MySQL Variante der LIMIT .. OFFSET Klausel SELECT * FROM BOOK LIMIT 2, 1 -- Derby, SQL Server 2012, Oracle 12c, und der SQL:2008 Standard SELECT * FROM BOOK OFFSET 2 ROWS FETCH NEXT 1 ROWS ONLY -- Informix hat SKIP .. FIRST Support SELECT SKIP 2 FIRST 1 * FROM BOOK -- Ingres (fast der SQL:2008 Standard) SELECT * FROM BOOK OFFSET 2 FETCH FIRST 1 ROWS ONLY -- Firebird SELECT * FROM BOOK ROWS 2 TO 3 -- Sybase SQL Anywhere SELECT TOP 1 ROWS START AT 3 * FROM BOOK -- DB2 (fast der SQL:2008 Standard, ohne OFFSET) SELECT * FROM BOOK FETCH FIRST 1 ROWS ONLY -- Sybase ASE, SQL Server 2008 (ohne OFFSET) SELECT TOP 1 * FROM BOOK Listing 21 Active Records Die meisten Schreib-Operationen sind trivi- ale „INSERT“- oder „UPDATE“-Befehle. Was mit JPA sehr einfach ist, funktioniert auch auf einer weniger komplexen Ebene mit soge- nannten „Active Records“, also Records, die eine Datenbank-Verbindung aufrechterhalten und alle Änderungen wieder zurückspeichern können. Listing 20 zeigt dazu ein Beispiel. Mit diesem API ist auch einfaches optimistisches Locking auf den Records möglich. Gespeicherte Prozeduren Nicht immer steht Java im Vordergrund einer Applikation. Um Performance zu erreichen oder um ein sauberes API zwischen der Da- tenbank und den Client-Applikationen umzu- setzen, werden oft gespeicherte Prozeduren verwendet. Der jOOQ Code Generator gene- riert auch hier Klassen mit Methoden, die den Prozeduren entsprechen, um mit wenig Pro- grammcode entsprechende Aufrufe machen zu können. Gespeicherte Funktionen können darüber hinaus auch direkt und typsicher in SQL-Befehlen verwendet werden, egal ob sie einen einzelnen Spaltenwert oder eine Tabel- le zurückgeben. SQL-Transformation und Standardisierung Der jOOQ-Programmierer baut keine SQL- Zeichenketten mehr, sondern direkt einen Abstract Syntax Tree (AST) in Java. Dieser kann nicht nur während der Kompilierung verwendet werden, sondern auch zur Lauf- zeit, um etwa zu entscheiden, in welcher exakten Form ein SQL-Befehl wirklich an die Datenbank ausgegeben werden soll. Der Entwickler kann einfach „selectFrom(BOOK). limit(1).offset(2)“ schreiben und jOOQ gene- riert das richtige SQL, je nach Datenbank- Dialekt, etwa in Datenbanken, die irgend- eine Form von „limit .. offset“ unterstützen (siehe Listing 21), aber auch in den anderen Datenbanken (siehe Listing 22). Insbesonde- re bei den letzteren Beispielen handelt es sich um die Art „Infrastruktur-Code“, die kein Entwickler wirklich schreiben möchte (oder auf Anhieb richtig hinbekommt). Fazit Interne domänen-spezifische Sprachen kön- nen in Java zu sehr viel Typsicherheit führen, fast so viel wie die externe Sprache selbst implementiert. Im Fall von SQL – einer sehr typsicheren Sprache – ist dies besonders interessant. jOOQ wurde konzipiert, um an der Java/ SQL-Schnittstelle möglichst viel der be- stehenden kognitiven Reibung bei Java- Entwicklern zu entfernen – vor allem bei den Entwicklern, die SQL in Java einbetten