3. Java Persistence API (JPA)

Transkript

1 3. Java Persistence API (JPA) Idee des Persistence Mapper Einfache Entity-Klasse Lebenslauf eines Entity-Objekts Umsetzung von 1:N- und M:N-Relationen Geordnete Daten Anfragen Vererbung Validierung 113

2 Literatur JSR 338: Java TM Persistence (JavaPersistence.pdf ist der Standard; trotzdem sehr gut lesbar!) Auch für Teile der weiteren Vorlesung C. Bauer, G. King, Java Persistence with Hibernate, Manning, Greenwich (USA) 2007 M. Keith, M. Schincariol, Pro EJB 3 - Java Persistence API, Apress, Berkeley (USA),

3 Klassische Wege zur Verbindung SW und DB DB werden meist nicht alleine entwickelt, sie müssen mit umgebender SW integriert werden. Es gibt verschiedene Ansätze, die gerade bei der Anbindung von OO-SW relevant sind: - SW wird (z.b: mit PL/SQL) in der Datenbank entwickelt (hierzu gibt es auch objektorientierte Ansätze), externe SW kann auf Prozeduren und Funktionen zugreifen. - SQL-Aufrufe werden direkt in die SW eingebettet (Embedded SQL) bzw. Aufrufe werden durch ein einfaches Framework (z.b. JDBC, SQLJ) gekapselt. (Frage: wie bekomme ich Objekte in die DB?) - DB- und SW- wird eng miteinander verzahnt, hierzu stehen ausgereifte Development- Frameworks zur Verfügung (EJB,.NET) 115

4 Motivation Relationale Datenbanken sind das Mittel zur Persistierung Objekte müssen damit in Datenbanken gespeichert und gefunden werden JDBC bietet alle Möglichkeiten; zur Vereinfachung wurden oft individuelle Abstraktionen darauf gesetzt Object Relational Mapper (ORM) standen in Konkurrenz, wurden dann mit JPA auf gemeinsamen Standard gesetzt Ziel 1: Aus Klassenmodell nahtlos Tabellen generieren und nutzen Ziel 2: Einfache Anbindung existierender Datenbanken an OO-Software Hinweis: JPA in Java SE und Java EE nutzbar 116

5 Erinnerung: Relationale Datenbanken Relationen (Tabellen) beschreiben einfache Entitäten Relationen beschreiben Verknüpfungen zwischen Entitäten (-> Fremdschlüssel) Modellierung mit ER-Diagramm Einfache Übersetzung in Tabellen Effizienter Zugriff mit SQL ACID-Transaktionen Zugriff von Java mit JDBC Wir nutzen JavaDB (Apache Derby) /index.html 117

6 Beispiel (1/7) package jpa20beispiel1; import javax.persistence.entity; import public class Mitarbeiter private int minr; // Primaerschluessel private String name; public Mitarbeiter(){ //parameterloser Konstruktor benötigt public Mitarbeiter(int minr, String name) { //erlaubt this.minr = minr; this.name = name; public int getminr() {return minr; public void setminr(int minr) {this.minr = minr; public String getname() {return name; public void setname(string name) {this.name = name; 118

7 Beispiel (2/7) persistence.xml liegt im Ordner META-INF (projektartabhängig) Detaileinstellungen von JPA-Realisierung abhängig (z. B. EclispeLink (basiert auf TopLink), Hibernate, Apache OpenJPA) <?xml version="1.0" encoding="utf-8"?> <persistence version="2.0" xmlns=" xmlns:xsi=" xsi:schemalocation=" <persistence-unit name="jpa20beispiel1pu" transaction-type="resource_local"> <provider> org.eclipse.persistence.jpa.persistenceprovider </provider> <class>jpa20beispiel1.mitarbeiter</class> 119

8 Beispiel (3/7) <properties> <property name="javax.persistence.jdbc.url" value="jdbc:derby://localhost:1527/spielerei"/> <property name="javax.persistence.jdbc.password" value="kleuker"/> <property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.clientdriver"/> <property name="javax.persistence.jdbc.user" value="kleuker"/> <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/> </properties> </persistence-unit> </persistence> 120

9 Beispiel (4/7) 121

10 Beispiel (5/7) package jpa20beispiel1; import java.util.list; import javax.persistence.entitymanager; import javax.persistence.entitymanagerfactory; import javax.persistence.persistence; public class Main { private EntityManagerFactory emf = Persistence. createentitymanagerfactory("jpa20beispiel1pu"); private EntityManager em = emf.createentitymanager(); public void beispieldaten() { String namen[] = {"Egon", "Erwin", "Ute", "Aische"; em.gettransaction().begin(); for (int i=0; i<namen.length; i++) em.persist(new Mitarbeiter(i,namen[i])); em.gettransaction().commit(); 122

11 Beispiel (6/7) public void datenzeigen() { for (Mitarbeiter m : em.createquery( "SELECT m FROM Mitarbeiter m",mitarbeiter.class).getresultlist()) { System.out.println(m.getMinr() + ": " + m.getname()); public void schliessen() { if (em!= null && em.isopen()) {em.close(); if (emf!= null && emf.isopen()) {emf.close(); public static void main(string[] args) { Main m = new Main(); m.beispieldaten(); m.datenzeigen(); m.schliessen(); 1: Egon 2: Erwin 4: Aische 3: Ute 123

12 Beispiel (7/7) Falls keine Tabelle Mitarbeiter existiert, wird diese angelegt 124

13 Suchen und Bearbeiten von einzelnen Objekten public void namenaendern(){ int eingabe=-1; while(eingabe!=0) { System.out.print("Welche Nummer (Ende mit 0): "); eingabe=new Scanner(System.in).nextInt(); Mitarbeiter m = em.find(mitarbeiter.class, eingabe); if(m == null) System.out.println("Witzbold"); else { System.out.print("Neuer Name (alt:"+m.getname()+"): "); String name=new Scanner(System.in).next(); EntityTransaction tr = em.gettransaction(); tr.begin(); m.setname(name); // em.merge(m); steht hier üblicherweise, geht ohne tr.commit(); 125

14 Zentrale Klassen Aufbau der Verbindung EntityManagerFactory emf = Persistence. createentitymanagerfactory("jpa20beispiel1pu"); Einrichtung sehr aufwändig, selten neu erstellen Einrichtung der Verbindung für den Nutzer EntityManager em = emf.createentitymanager(); kostet Zeit, längere Zeit nutzbar, ob mehrfach erzeugen oder nicht hängt von Rahmenbedingungen ab Nutzung einer Transaktion EntityTransaction tr = em.gettransaction(); kurzfristig nutzen: Daten vorbereiten, dann DB-Zugriff, dann schließen (zum Lesen nicht benötigt) letztendlich immer alles schließen (typisch in finally-block) Generelles Verhalten hängt von DB ab, in Großprojekten immer mit erfahrenem DB-Administrator arbeiten 126

15 Entity ist POJO Entity-Klassen-Objekte sind klassische Plain Old Java Objects Verpflichtung: public (oder protected) Konstruktor ohne Parameter Exemplarvariablen private oder protected, Zugriff über get... und set... Klasse, Methoden, Exemplarvariablen nicht final Serialisierbar keine weiteren Einschränkungen beliebige weitere Methoden Vererbung (auch Entity von Nicht-Entity [aufwändig]) Nutzung abstrakte Klassen 127

16 Id und equals Java regelt Gleichheit normalerweise über equals() und hashcode() nun existiert die Objekt-Id, die Objekte eindeutig identifizieren soll ein sinnvoller Ansatz: in equals() und hashcode() nur diese Id nutzen Konsequenz: keine inhaltliche Prüfung, sonstige inhaltliche Gleichheit wird nicht berücksichtigt beachten: das Objekt erhält seine Id erst mit der Persistierung Vergleich von persistierten und nicht persistierten Objekten dann nicht mehr möglich (auch von unpersistierten nicht) Fazit: Es gibt keine optimale Lösung für Gleichheit 128

17 Primary Key Typisch: Primary Key = GenerationType.AUTO) private int minr; folgende Datentypen erlaubt primitive Java-Typen (int, long, ) Wrapper von primitiven Java-Typen (Integer, Long, ) java.lang.string java.util.date java.sql.date 129

18 Persistierbare Typen/Klassen Primitive Typen (byte, char, int, long, float, double, boolean) java.lang.string Andere serialisierbare Typen: Wrapper der primitiven Typen java.math.biginteger java.math.bigdecimal java.util.date, java.util.calendar java.sql.date, java.sql.time, java.sql.timestamp Nutzerdefinierte serialisierbare Typen byte[], Byte[], char[], Character[] Enumeration Andere Entities Collections von Entities (Collection, Set, List, Map) 130

19 Persistent Fields / Properties Persistent private int minr; Exemplarvariablen direkt annotiert Zugriff des Persistence-Frameworks direkt auf Variablen Vorteil: Variable und Annotation stehen direkt zusammen Persistent public int getminr{ return this.minr; get-methode wird annotiert Zugriff auf Exemplarvariablen muss immer über Standard get erfolgen (auch in der Klasse selbst) Vorteil: Flexibilität, da Methode weitere Funktionalität haben kann 131

20 Annotationen zur Flexibilisierung public class Mitarbeiter implements Serializable { private static final long serialversionuid = GenerationType.AUTO) private int name="leiter", nullable=false,updatable=true, unique=true) private String name;

21 PersistenceContext Wird für Objekte vorher festgehaltener Klassen definiert Entspricht einem Cache, der MANAGED-Objekte verwaltet EntityManager-Objekt für konkreten PersistenceContext EntityManager-Operationen arbeiten auf dem Cache Man muss EntityManager mitteilen, dass Daten in die DB geschrieben werden müssen em.gettransaction().commit(); Beim Schreiben können wg. der Transaktionssteuerung der DB Exceptions auftreten (abhängig von Steuerungsart) Im Zweifel bei immer echte Tabellen anschauen Üblich: nur kurz lebende EntityManager (erzeugen, Aktion, schließen) 133

22 Beispiel für Cache public class Mitarbeiter implements private int //maximal zwei Zeichen private String name; public Mitarbeiter() { //parameterloser Konstruktor benötigt public Mitarbeiter(String name) { this.name = name; // get- und set-methoden public String tostring(){ return name+"("+minr+")"; 134

23 Beispiel für Cache (2/2) also kein Eintrag in der DB public static void main(string[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPACachePU"); EntityManager em=emf.createentitymanager(); em.gettransaction().begin(); em.persist(new Mitarbeiter("ET")); em.persist(new Mitarbeiter("JFK")); for(int i=1;i<3;i++) System.out.println(em.find(Mitarbeiter.class,i)); em.gettransaction().commit(); em.close(); ET(1) JFK(2) [EL Warning]: :12: UnitOfWork( )- Exception [EclipseLink-4002]: org.eclipse.persistence.exceptions.databaseexception Internal Exception: java.sql.sqldataexception: Bei dem Versuch, VARCHAR 'JFK' auf die Länge 2 zu kürzen, ist ein Abschneidefehler aufgetreten. 135

24 Lebenslauf eines Entity-Objekts NEW -> merge() führt evtl. zur Mehrfachobjekterzeugung refresh() nur, wenn vorher persistiert 136

25 Lebenslaufanalyse (1/13) - public class Mitarbeiter2 implements Serializable { private static final long serialversionuid = GenerationType.AUTO) private int id; // mit get- und set-methode private String name; // mit get- und set-methode public Mitarbeiter2(){ public Mitarbeiter2(int val, String name){ this.id = val; this.name = public String tostring() { return "["+this.id+": "+this.name+"]"; //

26 Lebenslaufanalyse (2/13) Umgebung (nichts Neues) public class Main2 { private EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPASpielereiPU2"); private EntityManager em = emf.createentitymanager(); //... persistence.xml: <persistence-unit name="jpaspielereipu2" transaction-type="resource_local"> <provider>org.eclipse.persistence.jpa.persistenceprovider </provider> <class>jpaspielerei.mitarbeiter2</class> <properties> <property name="javax.persistence.jdbc.url" value="jdbc:derby://localhost:1527/spielerei"/> <property name="javax.persistence.jdbc.password" value="kleuker"/>

27 Lebenslaufanalyse (3/13) - Analysemethode public void beinhaltet(int nr, Mitarbeiter2 ma) { System.out.println(nr + ": " + ma + ": "+ this.em.contains(ma)); Map<String, Object> map = this.em.getproperties(); System.out.println(" "); try (Connection con = DriverManager.getConnection((String)map.get("javax.persistence.jdbc.url"), (String)map.get("javax.persistence.jdbc.user"), (String)map.get("javax.persistence.jdbc.password"))) { Statement stmt = con.createstatement(); ResultSet rs = stmt.executequery("select * FROM Mitarbeiter2"); while (rs.next()) { System.out.print(rs.getString("id") + ": " + rs.getstring("name")+"\n"); catch(exception e){ System.out.println("Datenbankfehler: "+e.getmessage()); System.out.println(" \n"); 139

28 Lebenslaufanalyse (4/13) - Beispielschritte public void lifecycle1() { Mitarbeiter2 m = new Mitarbeiter2(1, "ich"); beinhaltet(0, m); 0: [1: ich]: false em.gettransaction().begin(); em.persist(m); beinhaltet(1, m); m m 1 ich 1 ich PC id id name name PC em.gettransaction().commit(); beinhaltet(2, m); m 1 ich PC id name 1 ich 140

29 Lebenslaufanalyse (5/13) - Beispielschritte m.setname("deep Thought"); beinhaltet(3, m); m 1 Deep Thought PC id name 1 ich em.refresh(m); beinhaltet(4, m); m 1 ich PC id name 1 ich m.setname("calculon"); beinhaltet(5, m); m 1 Calculon PC id name 1 ich Mitarbeiter2 m2 = em.merge(m); beinhaltet(6, m2); m m2 1 Calculon PC id name 1 ich 141

30 Lebenslaufanalyse (6/13) - Beispielschritte em.persist(m); beinhaltet(7, m); m m2 em.gettransaction().begin(); beinhaltet(8, m); m m2 1 Calculon 1 Calculon PC PC id name 1 ich id name 1 ich em.gettransaction().commit(); beinhaltet(9, m); m m2 1 Calculon PC id name 1 Calculon persist(.) gibt nur an, dass ein Objekt gespeichert werden soll, dies ist außerhalb von Transaktionen möglich (man sollte aber einheitlichen Stil nutzen und dies vermeiden) 142

31 Lebenslaufanalyse (7/13) - Beispielschritte m.setname("linguo"); em.gettransaction().begin(); em.gettransaction().commit(); beinhaltet(10, m); em.clear(); beinhaltet(11, m); m m2 1 Linguo m m2 1 Linguo PC PC id name 1 Linguo id name 1 Linguo Sollen in einer Transaktion zwischenzeitlich alle SQL-Befehle ausgeführt, dann weitere Aktionen und dann ein commit ausgeführt werden, wird em.flush() genutzt 143

32 Lebenslaufanalyse (8/13) - Beispielschritte m2 = em.find(mitarbeiter2.class, 1); System.out.println("m == m2 : "+(m == m2)); m.setname("hal"); m2.setname("eve"); beinhaltet(12, m); beinhaltet(13, m2); m 1 HAL m = em.merge(m); beinhaltet(14, m); beinhaltet(15, m2); m2 m m2 1 EVE 1 HAL PC PC // false id name 1 Linguo id name 1 Linguo System.out.println("m == m2 :"+(m==m2)); // true merge(.) aktualisiert/vermischt lokales PC-Objekt mit Daten des übergebenen Objektes und gibt PC-Objekt zurück 144

33 Lebenslaufanalyse (9/13) - Fazit man sollte wissen, welche Objekte sich im Persistence Context (PC) jeweils befinden man braucht definitiv nicht alle gezeigten Varianten typischer Ansatz sehr kurze Transaktionen persist(.) und remove(.) finden in den Transaktionen statt merge(.) seltener, aber notwendig, um lokale Änderungen in PC zu übertragen wenn man aufräumen will clear() explizit nutzen weitere Befehle nur nutzen, wenn unbedingt notwendig vom Ansatz abweichen, wenn viele Transaktionen SW ausbremsen (dann wird es kompliziert) 145

34 Lebenslaufanalyse (10/13) Zweites Beispiel public void lifecycle2() { Mitarbeiter2 m = new Mitarbeiter2(1, "ich"); Mitarbeiter2 m2 = new Mitarbeiter2(1, "Nono"); try { em.gettransaction().begin(); em.persist(m); beinhaltet(1, m); m2 1 Nono m 1 ich PC id name em.persist(m2); beinhaltet(2, m2); m m2 1 ich 1 Nono PC id name em.gettransaction().commit(); 146

35 Lebenslaufanalyse (11/13) Zweites Beispiel m catch (Exception e) { System.out.println(e.getMessage()); if (em.gettransaction().isactive()) { em.gettransaction().rollback(); System.out.println("rolled back"); // liefert nur Internal Exception: // java.sql.sqlintegrityconstraintviolationexception: beinhaltet(3, m); 1 ich m2 1 Nono PC id name 147

36 Lebenslaufanalyse (12/13) Zweites Beispiel em.persist(m); em.gettransaction().begin(); em.gettransaction().commit(); beinhaltet(4, m); m2 em.persist(m2); beinhaltet(5, m2); em.refresh(m2); beinhaltet(6, m2); 1 Nono m m m2 m m2 1 ich 1 ich 1 ich 1 Nono 1 ich em.gettransaction().begin(); em.gettransaction().commit(); // java.sql.sqlintegrityconstraintviolationexception PC PC PC id name 1 ich id name 1 ich id name 1 ich 148

37 Lebenslaufanalyse (13/13) SQL-Befehle sichtbar für Eclipselink in persistence.xml: <property name="eclipselink.logging.level" value="severe"/> <property name="eclipselink.logging.level" value= FINE"/> <property name="eclipselink.logging.level" value= FINEST"/> allgemein ab JPA 2.1, SQL-Skripte erzeugen <property name="javax.persistence.schema-generation.scripts.action" value="drop-and-create"/> <property name="javax.persistence.schema-generation.scripts.drop-target" value="mydrop.ddl"/> <property name="javax.persistence.schema-generation.scripts.create-target" value="mycreate.ddl"/> 149

38 Sauberes Persistieren Auslagerung der Persistierung in eine Methode mit sauberer Exception-Behandlung Anmerkung: man muss nicht immer em.close() machen public void persist(object object) { em.gettransaction().begin(); try { em.persist(object); em.gettransaction().commit(); catch (Exception e) { if (em.gettransaction().isactive()) em.gettransaction().rollback(); throw e; // oder neue Exception finally { em.close(); 150

39 oftmals sinnvoll: DB-Zugriffe zentralisieren (1/3) neue Schicht: eine oder mehrere Klassen, die JPA-Zugriffe durchführen für Entwickler einfacher: ggfls. nicht im Detail über Persistence Context nachdenken public class Persistierer { private EntityManagerFactory emf; private EntityManager em; public Persistierer(String persistence) { emf = Persistence.createEntityManagerFactory(persistence); em = emf.createentitymanager(); 151

40 oftmals sinnvoll: DB-Zugriffe zentralisieren (2/3) public void persist(object ob) { em.gettransaction().begin(); try { em.persist(ob); em.gettransaction().commit(); catch (Exception e) { // evtl Logging throw e; // remove(object ob) analog public Object merge(object ob) { Object erg = null; em.gettransaction().begin(); try { erg = em.merge(ob); em.gettransaction().commit(); catch (Exception e) { throw e; return erg; Exception-Handling muss im Projekt geklärt werden JPA-Exception müssen weder gefangen noch deklariert werden meist nach oben reichen (und dabei noch umwandeln) 152

41 oftmals sinnvoll: DB-Zugriffe zentralisieren (3/3) public Mitarbeiter findmitarbeiter(long id) { return em.find(mitarbeiter.class, id); public List<Mitarbeiter> findallmitarbeiter() { return em.createquery( "SELECT m FROM Mitarbeiter m",mitarbeiter.class).getresultlist(); public void schliessen() { if (em!= null && em.isopen()) { em.close(); if (emf!= null && emf.isopen()) { emf.close(); 153

42 Klasse oder Tabelle? Bei der Entity-Nutzung offen, ob erst Klassen designt und dann Tabellen entworfen werden Einfach: Tabellen existieren; dann typischerweise zur Tabelle eine Entity-Klassse erstellbar (generierbar) Wenn nichts gegeben: Entwurf der Entity-Klassen (Daten der Applikation mit ihren Abhängigkeiten) Ableitung oder Generierung der Tabellen Generierungsansätze: Drop and Create: beteiligte Tabellen löschen und neu anlegen ( und Test) Create: wenn nicht existent, dann anlegen (Realität) None: wenn nicht existent, dann Fehler (Realität) Hinweis: bei Änderungen neu übersetzen 154

43 Generelle JEE-Regel Convention over Configuration bedeutet: wenn nichts angegeben wird, wird ein Default- Wert genutzt Default-Werte sind zwar sinnvoll, sollte man aber kennen Erinnerung: Java-Inkonsistenz 155

44 Einschub: XML-Konfiguration Statt Annotationen zu nutzen, können diese Informationen auch in XML beschrieben werden Typisch: eine XML-Datei pro Klasse + zusammenführende XML-Datei Vorteil: Verhaltensänderungen ohne Codeänderung Nachteil: viele kleine penibel zu pflegende Dateien Auch möglich: XML und Annotationen; dabei schlägt XML die Annotationen 156

45 Kardinalitäten in JPA A x 1:1 zu einem A- Objekt gehört (maximal) ein anderes B- Objekt, die jeweils zu (maximal) einem A-Objekt gehören 1:N zu einem A-Objekt gehören beliebig viele B-Objekte, die jeweils zu (maximal) einem A-Objekt gehören (N:1 analog) M:N zu einem A-Objekt gehören beliebig viele B-Objekte, die jeweils zu beliebig vielen A-Objekten gehören Anders als bei Tabellen haben OO-Assoziationen Leserichtungen Unidirektional: nur von einer Seite auf die andere schließbar Bidirektional: Abhängigkeit in beide Richtungen manövrierbar (es gibt Besitzer der Beziehung; für Updates wichtig) y B 157

46 Zielsoftware Sprinter Verwaltung von Sprints, in denen BacklogElemente abgearbeitet werden Zu jedem BacklogElement gibt es einen Menge von Mitarbeiten (Teilaufgaben) Jeder Mitarbeiter kann an mehreren Mitarbeiten mitwirken Das Werkzeug soll Informationen über den aktuellen Stand von BacklogElementen und Sprints ausgeben 158

47 Hintergrund Im agilen Vorgehensmodell wird Projekt in mehrere Sprints aufgeteilt (diese Aufgaben stehen im Product-Backlog) Arbeiten in einem Sprint werden Backlog-Elemente genannt Backlog-Elemente werden von Mitarbeitern abgearbeitet Prozess: 1. aus Sprint-Länge und Anzahl der Mitarbeiter wird maximal verfügbare Stundenzahl berechnet 2. Festlegung der (Sprint-)Backlog-Elemente, die im Sprint zu erledigen sind, mit Aufwandsschätzung durch Mitarbeiter 3. Festlegung der durchführenden Mitarbeiter mit Arbeitsanteil 4. ggfls. Anpassung der für Sprint zur Verfügung stehenden Stundenanzahl 159

48 Ausschnitt 160

49 Datenmodell 161

50 Umsetzungen von Beziehungen Datenbanken kennen drei wesentliche Kardinalitäten für Beziehungen 1-1, 1-N, M-N diese werden bei Objektvariablen direkt an die Beziehung Zuordnung zu (maximal) einem Zuordnung von beliebig vielen Objekten (steht typischerweise bei Zuordnung zu einem Objekt (kann selbst mehrfach zugeordnet sein, steht, wenn benötigt, auf anderer Zuordnung von beliebig vielen Objekten, die auch wahrscheinlich in die Rückrichtung genutzt wird 162

51 Erinnerung: Umsetzung 1:N bei Datenbanken (1/3) Zu jedem BacklogElement gehören beliebig viele Mitarbeiten Jede Mitarbeit gehört zu genau einem BacklogElement Standardumsetzung pro Entität eine Tabelle in Tabelle Mitarbeit wird die id des zugehörigen BacklogElements als Fremdschlüssel eingetragen 163

52 Erinnerung: Umsetzung 1:N bei Datenbanken (2/3) Erster Umsetzungsversuch BacklogElement hat eine Collection von Mitarbeiten kleines fachliches Problem: Mitarbeit kennt nicht zugehöriges BacklogElement großes fachliches Problem: eine Mitarbeit kann immer noch zu mehreren unterschiedlichen BacklogElementen gehören konsequente automatische JPA-Umsetzung: dritte Tabelle mit Fremdschlüsseln verknüpfter Objekte (wie M-N) 164

53 Erinnerung: Umsetzung 1:N bei Datenbanken (3/3) Umsetzung (im Wesentlichen Identisch zum DB-Ansatz) Bidirektionale Beziehung (Nachteil beide Richtungen immer pflegen) immer noch könnte ein Mitarbeit-Objekt zu einem anderen BacklogElement-Objekt gehören, als in dessen Collection es ist Lösung durch mappedby-atribut Verknüpfung = "backlogelement") private List<Mitarbeit> mitarbeiten; 165

54 Wichtige Annotationen in int version Attribut wird für das optimistische Locking genutzt; erst beim Schreiben geschaut, ob sich Versionsnummer geändert hat performant, wenn Objekte nicht häufig geändert werden Einfach als zusätzliches Attribut private Set<Mitarbeiter> mitarbeiter EAGER: Alle Daten des Attributs werden bei Objektnutzung sofort in Hauptspeicher geladen LAZY: Daten werden erst geladen, wenn benötigt Längere Listen oder komplexe Daten möglichst immer LAZY (versteckte Konsistenzprobleme möglich) Wenn eine Info sofort benötigt, ist Kette zur Info EAGER 166

55 Umsetzung des Beispiels (1/9): Klassendiagramm 167

56 Umsetzung des Beispiels (2/9): public class BacklogElement implements = GenerationType.AUTO) private long private int private String titel; private int mappedby = "backlogelement", fetch = FetchType.EAGER) private List<Mitarbeit> private Phase phase; Werte als Strings, nicht Ordnungsnummern, speichern (besser bei Änderungen) 168

57 Umsetzung des Beispiels (3/9): Enumeration public enum Phase { ZU_BEARBEITEN("zu bearbeiten"), VORBEREITUNG_IN_ARBEIT("Vorbereitung in Arbeit"), VORBEREITUNG_ABGESCHLOSSEN("Vorbereitung abgeschlossen"), ENTWICKLUNG_IN_ARBEIT(" in Arbeit"), ENTWICKLUNG_ABGESCHLOSSEN(" abgeschlossen"), TEST_IN_ARBEIT("Test in Arbeit"), TEST_ABGESCHLOSSEN("Test abgeschlossen"), ABNAHME_IN_ARBEIT("Abnahme in Arbeit"), ABNAHME_ABGESCHLOSSEN("Abnahme abgeschlossen"), FERTIG("fertig"); private String text; Phase(String text){ this.text = public String tostring() { return this.text; 169

58 Umsetzung des Beispiels (4/9): public class Mitarbeit implements = GenerationType.AUTO) private long private int version; private int geplantestunden; private int verbrauchtestunden; private int fertigstellungsgrad; private String private Mitarbeiter private BacklogElement backlogelement; 170

59 Umsetzung des Beispiels (5/9): public class Mitarbeiter implements = GenerationType.AUTO) private long private int = true) private int minr; private String = "mitarbeiter", fetch = FetchType.EAGER) private List<Mitarbeit> mitarbeiten; 171

60 Umsetzung des Beispiels (6/9): Datenerzeugung 1/2 private String[] backlog =...; private String[] aufgaben =...; public void zuordnen() { this.pers = new Persistierer("SprinterJSE"); for (String bl : this.backlog) { BacklogElement b = new BacklogElement(bl, 42); pers.persist(b); this.backlogids.add(b.getid()); int minr = 1000; //+ (int)(math.random()*99000); for (String n : this.namen) { Mitarbeiter m = new Mitarbeiter(minr++, n); pers.persist(m); this.mitarbeiterids.add(m.getid()); 172

61 Umsetzung des Beispiels (7/9): Datenerzeugung 2/2 int pos = 0; for (String a : this.aufgaben) { Mitarbeit m = new Mitarbeit(20, 12, 70, a); pers.persist(m); BacklogElement b = pers.findbacklogelement(this.backlogids.get(pos / 2)); b.addmitarbeit(m); pers.merge(b); m.setbacklogelement(b); Mitarbeiter ma = pers.findmitarbeiter(this.mitarbeiterids.get(pos * 7 % this.mitarbeiterids.size())); ma.addmitarbeit(m); pers.merge(ma); m.setmitarbeiter(ma); // pers.merge(m); pos++; Auswahl eines passendes Objekt anhand einer vorhandenen Id (Details uninteressant) 173

62 Umsetzung des Beispiels (8/9): Mitarbeit-Erzeugung sicherer / konservativer Ansatz Mitarbeit anlegen und persistieren Mitarbeit bei BacklogElement hinzufügen BacklogElement mergen BacklogElement bei Mitarbeit hinzufügen Mitarbeit bei Mitarbeiter hinzufügen Mitarbeiter mergen Mitarbeiter bei Mitarbeit hinzufügen Mitarbeit mergen ist hier unnötig 174

63 Umsetzung des Beispiels (9/9): Ergebnisanalyse Ansatz funktioniert Mitarbeit hat bereits Versionsnummer 3 Versionsnummer, da angelegt und mit BacklogElement sowie Mitarbeiter aktualisiert (diese erkennen die aktuelle Version nicht) Im Fall BacklogElement Mitarbeit-Mitarbeiter kann auf cascade = {CascadeType.PERSIST, CascadeType.MERGE verzichtet werden (ist hier so), muss es aber nicht 175

64 Löschen Löschen ohne CascadeType.remove verläuft wieder völlig analog zu klassischen Datenbanken Löschen eines BacklogElements public void removebacklogelement(backlogelement b) { for (Mitarbeit m : b.getmitarbeiten()) { Mitarbeiter ma = m.getmitarbeiter(); if (ma!= null) { ma.removemitarbeit(m); merge(ma); remove(m); remove(b); zugehörige Mitarbeiten bei Mitarbeiter löschen 176

65 CascadeType.MERGE) MERGE : merge() implizit für verknüpfte Objekte aufrufen PERSIST: persist() implizit für verknüpfte Objekte aufrufen REFRESH: refresh() implizit für verknüpfte Objekte aufrufen REMOVE: remove() implizit für verknüpfte Objekte aufrufen ALL: alle vier genannten Möglichkeiten Default-Einstellung: keine der fünf Varianten Wichtige Design-Entscheidung, was sinnvoll ist REMOVE nur nutzbar Beispiel, wenn Cascade.PERSIST fehlte SCHWERWIEGEND: Could not synchronize database state with session org.hibernate.transientobjectexception: object references an unsaved transient instance - save the transient instance before flushing: Projektauftrag 177

66 Weitere interessante Annotationen / Attribute Variable wird nicht zur Nutzung von private Date starttermin; zur Sicherstellung der private List<Mitarbeiter> mitarbeiter = new ArrayList<>(); bei Existenzabhängigkeit, Löschen der abhängigen = {CascadeType.ALL, orphanremoval=true) einfache Nutzung von Vererbung (drei SINGLE_TABLE) 178

67 Anfragen Anfragesprache soll möglichst Entity-Objekte liefern Anfragesprache soll DB-unabhängig sein (SQL-Detailproblem) Antwort: Java Persistence QL (JPQL) Ermöglicht direkte Zurückgabe von Entitätsobjektlisten Ermöglicht auch direkte Ausführung von SQL-Anfragen Anmerkung: Vorgänger JDO unterstützte OO-Features in JDO- QL (Methodennutzung); dies ist nicht mehr möglich Typische Struktur: SELECT p FROM Projekt p WHERE <Bed> Übersetzung: Wähle aus der Menge Projekt der gemanageten Objekte die Elemente p mit Eigenschaft <Bed> 179

68 Anfrageausführung in Persistierer Setzt ordentliches tostring() voraus ist nicht typsicher public void anfragen(string ql) { try { Query query = em.createquery(ql); Collection erg = query.getresultlist(); for (Iterator it = erg.iterator(); it.hasnext();) { System.out.println(it.next()); catch (Exception e) { System.out.println("Anfrage gescheitert: " + e.getmessage()); 180

69 Einfache Beispiele Vorbemerkung: In FROM-Zeilen stehen Klassen und Attributnamen; bei diesen muss Groß- und Kleinschreibung beachtet werden! SELECT b FROM BacklogElement b (1) Klassenmodellierung (2) CRUD-Umsetzung [9 Ergebnisse] Direkter Zugriff auf Attribute SELECT b.titel FROM BacklogElement b Klassenmodellierung CRUD-Umsetzung [9 Ergebnisse] 181

70 Nutzung mehrwertiger Relationen SELECT b.mitarbeiten FROM BacklogElement b Mitarbeit [id=19, version=3, geplantestunden=20, verbrauchtestunden=12, fertigstellungsgrad=70] Ergebnis wird geflattened (vereinigt) Mitarbeit [id=20, version=3, geplantestunden=20, verbrauchtestunden=12, fertigstellungsgrad=70] [18 Ergebnisse] Nicht erlaubt: SELECT b.mitarbeiten.mitarbeiter FROM BacklogElement b An exception occurred while creating a query in EntityManager: Exception Description: Problem compiling [SELECT b.mitarbeiten.mitarbeiter FROM BacklogElement b]. [7, 32] The state field path 'b.mitarbeiten.mitarbeiter' cannot be resolved to a valid type. 182

71 JOIN-Varianten SELECT mi.name FROM Mitarbeit ma, Mitarbeiter mi WHERE ma.mitarbeiter = mi AND ma.backlogelement.titel = 'Klassenmodellierung' Homer Simpson Edna Krabappel bringt gleiches Ergebnis wie vorher, ist aber objektorientierter SELECT mi.name FROM Mitarbeit ma JOIN ma.mitarbeiter mi WHERE ma.backlogelement.titel = 'Klassenmodellierung' 183

72 Neu zusammengesetzte Ergebnisse SELECT b.titel, b.geplanteraufwand FROM BacklogElement b [Ljava.lang.Object;@640334cb [Ljava.lang.Object;@e7f2eb9 [9 Ergebnisse] detaillierter mit nachfolgender Methode anfrage2 SELECT b.titel, b.geplanteraufwand FROM BacklogElement b [Ljava.lang.Object;@59f31dd3 :: [Ljava.lang.Object; Klassenmodellierung 42 [Ljava.lang.Object;@682b35c7 :: [Ljava.lang.Object; CRUD-Umsetzung 42 [9 Ergebnisse] 184

73 Ausgabe mit detaillierterer Analyse public void anfragen2(string ql) { System.out.println(ql); try { Query query = em.createquery(ql); Collection erg = query.getresultlist(); for (Iterator it = erg.iterator(); it.hasnext();) { Object o = it.next(); System.out.println(o+" :: "+ o.getclass().getname()); if(o.getclass().getname().equals("[ljava.lang.object;")){ Object oa[]= (Object[]) o; for(int i=0;i<oa.length;i++) System.out.println(" "+oa[i]); catch (Exception e) { System.out.println("Anfragefehler: " + e.getmessage()); 185

74 Vordefinierte Anfragen + typisches Problem private final String backlogelementmit = "SELECT b.titel " + " FROM BacklogElement b JOIN b.mitarbeiten ma " + " JOIN ma.mitarbeiter mi" + " WHERE mi.name = :name"; public void backlogelementemit(string n) { Query query = this.pers.getem().createquery(this.backlogelementmit).setparameter("name", n); Collection erg = query.getresultlist(); for (Iterator it = erg.iterator(); it.hasnext();) { System.out.println(it.next()); 186

75 echte Standardkonformität? gerade bei Anfragen häufig keine 100%-Kompatibilität trotzdem: Immer sinnvoll, Objektauswahlen in Anfragesprache durchzuführen, nicht alle Objekte aus DB lesen und dann verarbeiten JPQL unterstützt mittlerweile fast alle SQL-Standard- Operatoren, selbst wenn diese aus OO-Sicht fragwürdig sind SUM AVG COUNT MIN MAX GROUP BY HAVING ORDER BY DISTINCT EXISTS ANY ALL trotzdem aufpassen: Fehler können andeuten, dass Detail noch nicht offiziell unterstützt wird 187

76 Klassische SQL-Operatoren SELECT b.titel, SUM(b.geplanterAufwand), SUM(ma.geplanteStunden) FROM BacklogElement b JOIN b.mitarbeiten ma GROUP BY b.titel [Ljava.lang.Object;@64114e1a :: [Ljava.lang.Object; Architektur [Ljava.lang.Object;@2c1ec049 :: [Ljava.lang.Object; Basisdienste [9 Ergebnisse] 188

77 Named @NamedQuery(name = "BacklogElement.findAll", query = "SELECT o FROM BacklogElement = "BacklogElement.findMitarbeit", query = "SELECT DISTINCT m " + " FROM BacklogElement b JOIN b.mitarbeiten m " + " WHERE b.id = :id " + "ORDER BY m.fertigstellungsgrad DESC") ) public class BacklogElement implements Serializable {... zentrales Ziel: alle Anfragen vorformuliert in Entity-Klassen; ein Vorteil: Syntaxprüfung bereits bei Kompilierung 189

78 Named Queries (2/2) Nutzung: hier in Persistierer public List<BacklogElement> findallbacklogelement() { return em.createnamedquery("backlogelement.findall").getresultlist(); public List<Mitarbeit> findallbacklogelementmitarbeit(long id) { return em.createnamedquery("backlogelement.findmitarbeit").setparameter("id", id).getresultlist(); Anmerkung: einzelne Objekte per Id immer mit em.find() suchen, da so automatisch im Persistence Context 190

79 Ungeordnete Daten public class Punkt private int id; private int x; private int private int version; public Punkt(int x, int y) { this.x = x; this.y = y; public public String tostring(){ return "["+x+","+y+"]"; // get- und set-methoden für Exemplarvariablen Problem: Auch Listen werden ungeordnet gespeichert 191

80 Ungeordnete Daten public class Polygon private int = {CascadeType.ALL) private List<Punkt> punkte= new private int version; public Polygon(){ //get und set für Exemplarvariablen public void punktehinzu(punkt... pkte){ for(punkt p:pkte) public String tostring(){ StringBuffer erg=new StringBuffer("<"); for(punkt p:punkte) erg.append(p.tostring()); return erg.append(">").tostring(); 192

81 Ungeordnete Daten (3/4) public class Main { private EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPA20NeueFeaturesPU"); private EntityManager em = emf.createentitymanager(); public void objekteerzeugen(){ Punkt[] pkt={new Punkt(0,0), new Punkt(5,3), new Punkt(3,3), new Punkt(3,0); em.gettransaction().begin(); for(punkt p:pkt) em.persist(p); em.gettransaction().commit(); Polygon p1 = new Polygon(); p1.punktehinzu(pkt[0],pkt[1],pkt[2]); Polygon p2 = new Polygon(); p2.punktehinzu(pkt[3],pkt[2],pkt[1]); em.gettransaction().begin(); em.persist(p1); em.persist(p2); em.gettransaction().commit(); 193

82 Ungeordnete Daten (4/4) public void zeigepolygone(){ List<Polygon> pl = em.createquery( "SELECT p FROM Polygon p",polygon.class).getresultlist(); for(polygon po:pl) System.out.println(po); public void schliessen() { if (em!= null && em.isopen()) em.close(); if (emf!= null && emf.isopen()) emf.close(); public static void main(string[] args) { Main m= new Main(); m.objekteerzeugen(); m.zeigepolygone(); m.schliessen(); System.out.println("----"); m= new Main(); m.zeigepolygone(); m.schliessen(); <[0,0][5,3][3,3]> <[3,0][3,3][5,3]> ---- <[0,0][5,3][3,3]> <[5,3][3,3][3,0]> 194

83 Ordnung public class Polygon private int = {CascadeType.PERSIST, private List<Punkt> punkte= new private int version; <[3,0][3,3][5,3]> <[0,0][5,3][3,3]> ---- <[3,0][3,3][5,3]> <[0,0][5,3][3,3]> Hinweis: persistence.xml mit create 195

84 Standard: keine Löschfortsetzung (1/2) public void objekteerzeugen() { Punkt[] pkt = {new Punkt(0, 0), new Punkt(5, 3), new Punkt(3, 3); Polygon p1 = new Polygon(); p1.punktehinzu(pkt[0], pkt[1], pkt[2]); em.gettransaction().begin(); em.persist(p1); em.gettransaction().commit(); public void objektebearbeiten() { Polygon pl = em.createquery("select p FROM Polygon p", Polygon.class).getResultList().get(0); pl.getpunkte().remove(1); em.gettransaction().begin(); em.persist(pl); em.gettransaction().commit(); 196

85 Standard: keine Löschfortsetzung (2/2) public void zeigepolygoneundpunkte() { for (Polygon po : em.createquery("select p FROM Polygon p", Polygon.class).getResultList()) System.out.println(po); System.out.println("----"); for (Punkt pu : em.createquery("select p FROM Punkt p", Punkt.class).getResultList()) System.out.println(pu); public static void main(string[] args) { Main m = new Main(); m.objekteerzeugen(); m.objektebearbeiten(); m.zeigepolygoneundpunkte(); m.schliessen(); <[0,0][3,3]> ---- [0,0] [5,3] [3,3] 197

86 Löschfortsetzung Anmerkung: auch keine Löschung alleine durch CASCADETYPE.ALL in Polygon, aber durch folgende = private List<Punkt> punkte = orphanremoval=true) new ArrayList<Punkt>(); <[0,0][3,3]> ---- [0,0] [3,3] Was passiert, wenn mehrere Objekte Punkt referenzieren (widerspricht der Eigentümerschaft)? Exception in thread "main javax.persistence.rollbackexception Caused by: java.sql.sqlintegrityconstraintviolationexception: DELETE in Tabelle 'PUNKT' hat für Schlüssel (3) die Integritätsbedingung 'PLYGONPUNKTPNKTEID' für Fremdschlüssel verletzt. 198

87 Vererbung eine Tabelle public class Produkt implements private int prnr; private String name; private int lagermenge; private float private int public class Lebensmittel extends Produkt implements private Date public class Buch extends Produkt{

88 Vererbung eine Tabelle (2/3) public static void main(string[] args) { EntityManagerFactory emf =Persistence. createentitymanagerfactory("jpavererbungpu"); EntityManager em=emf.createentitymanager(); em.gettransaction().begin(); em.persist(new Buch("JPA", 2, 39.99f)); em.persist(new Produkt("Maus", 4, 7.99f)); em.persist(new Lebensmittel("Tofu", 7, 0.69f,new Date())); em.gettransaction().commit(); for(produkt p:(list<produkt>)em.createquery("select p FROM Produkt p").getresultlist()) System.out.println(p); 1:JPA Menge:2 Preis:39.99 Buch 2:Maus Menge:4 Preis:7.99 3:Tofu Menge:7 Preis:0.69 Verfall:Thu Oct 15 16:22:14 CEST

89 Vererbung eine Tabelle (3/3) SELECT * FROM Produkt Abbildung in eine Tabelle ist Default-Einstellung Ansatz meist am performantesten (float ungeeignet für Geldbeträge) 201

90 Vererbung getrennte public class Produkt implements Serializable {... SELECT * FROM Produkt SELECT * FROM Lebensmittel SELECT * FROM Buch 202

91 Vererbung public class Produkt implements Serializable {... SELECT * FROM Produkt SELECT * FROM Lebensmittel SELECT * FROM Buch 203

92 Überwachungsmethoden public class private int minr; private String name; private void p(string public void prepersit() public void postpersist() public void preremove() public void postremove() public void preupdate() public void postupdate() public void postload() {p("postload"); // Hinweis: Rollback bei einer Runtime Exception

93 Überwachungsmethoden (2/3) public static void main(string[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("PrePostPU"); EntityManager em = emf.createentitymanager(); Mitarbeiter m = new Mitarbeiter("Olga"); prepersist Mitarbeiter m2 = new Mitarbeiter("Otto"); prepersist EntityTransaction ta = em.gettransaction(); prepersist ta.begin(); postpersist em.persist(m); postpersist em.persist(m2); postpersist em.persist(new Mitarbeiter("Urs")); preupdate ta.commit(); postupdate ta.begin(); Mitarbeiter mm = em.find(mitarbeiter.class, m.getminr()); mm.setname("anna"); em.persist(mm); ta.commit(); 205

94 Überwachungsmethoden (3/3) ta.begin(); em.remove(m); ta.commit(); em.close(); // notwendig für neuen Kontext em = emf.createentitymanager(); for (Mitarbeiter m3 : em.createquery( "SELECT m FROM Mitarbeiter m", Mitarbeiter.class).getResultList()) System.out.println(m3.getMinr() + ": " + m3.getname()); em.close(); emf.close(); preremove postremove postload postload 2: Otto 3: Urs 206

95 Interessante weitere Features in JPA in Anfrage-Sprache Funktionen auf Datentypen z. B. SUBSTRING(String,Start,Ende) UPDATE und DELETE in Querys JOIN FETCH garantiert Eager Loading immer vor/nach Persistierung ausgeführte Methoden (ersetzen Trigger) Compound Primary Keys, zusammengesetzte Schlüssel über Hilfsklassen private byte[] 207

96 Einbindung von Bean-Validation Annotationen ermöglichen bereits Angabe bestimmter Randbedingungen klarerer Ansatz: Trennung von Beschreibung des Objektgraphen (wer mit wem) von Validierung Bean-Validation kann zusammen mit JPA genutzt werden; Anwesenheit von Validatoren wird von EntityManagern genutzt Ansatz: Wenn Daten in DB persistiert werden sollen, werden alle Validierungsregeln geprüft (nicht eher); bei Fehler wird Exception geworfen Zukunft: Standards werden noch enger verknüpft Beispiel: externe Programmierernamen beginnen mit X, müssen eine der vorgegebenen Sprachen können 208

97 Validierung von Mitarbeiter public class Mitarbeiter implements = GenerationType.AUTO) private long private int = message="mitarbeiternummer nicht negativ") private int muss angegeben message="name darf nicht leer sein") private String = "mitarbeiter", fetch = private List<Mitarbeit> mitarbeiten; 209

98 Erinnerung (1/3): eigene Validierungsannotation auf Mitarbeiten verteilter Aufwand darf nicht höher als für BacklogElement angesetzter Aufwand sein neue Annotation BacklogElementCheck: import javax.validation.constraint; import javax.validation.payload; @Constraint(validatedBy = BacklogElementCheck { String message() default "Aufwandsverteilung " + "bei BacklogElement beachten"; Class<?>[] groups() default {; Class<? extends Payload>[] payload() default {; 210

99 Erinnerung (2/3): eigene Validierungsannotation public class implements ConstraintValidator <BacklogElementCheck,BacklogElement> { public void initialize(backlogelementcheck anno) { // hier Zugriff auf Attributswerte der public boolean isvalid(backlogelement value int verteiltearbeit = 0;, ConstraintValidatorContext context) { for(mitarbeit m: value.getmitarbeiten()){ verteiltearbeit += m.getgeplantestunden(); 211

100 Erinnerung (3/3): eigene Validierungsannotation if (verteiltearbeit > value.getgeplanteraufwand()){ context.disabledefaultconstraintviolation(); context.buildconstraintviolationwithtemplate( "Backlog-Element: Verteilter Aufwand darf nicht über " + "geplantem Aufwand liegen").addconstraintviolation(); return false; if(value.getphase().equals(phase.fertig) && value.fertigstellung() < 99.99){ context.disabledefaultconstraintviolation(); context.buildconstraintviolationwithtemplate( "Backlog-Element: Zum Übergang nach Fertig müssen alle " + "Arbeiten abgeschlossen sein").addconstraintviolation(); return false; return true; 212

101 Nutzung public class BacklogElement implements = GenerationType.AUTO) private long private int private String message = "geplanter Aufwand nicht negativ") private int = private List<Mitarbeit> private Phase phase; 213

102 Prüfung der Annotation lokal (1/2)- Auswertung public class ValidateMain<T> { // T ist zu analysierende Klasse public int analyse(t o, Class... grp) { System.out.println("Analyse von " + o); ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getvalidator(); Set<ConstraintViolation<T>> cv = validator.validate(o,grp); for (ConstraintViolation<T> c : cv) System.out.println(" :: " + c.getmessage()); return cv.size();... // main-methode mit Beispiel Anmerkung: Exception-Lösung leicht realisierbar if(cv.size()>0) throw new IllegalArgumentException(...) 214

103 Prüfung der Annotation lokal (2/2) public static void main(string[] s){ ValidateMain<BacklogElement> val = new ValidateMain<>(); BacklogElement b = new BacklogElement("",-42); Mitarbeit m1 = new Mitarbeit(30); Mitarbeit m2 = new Mitarbeit(-3); b.addmitarbeit(m1); b.addmitarbeit(m2); val.analyse(b); ein BacklogElement mit zwei Mitarbeiten Analyse von (0) :: Geplante Stunden nicht negativ :: Backlog-Element: Verteilter Aufwand darf nicht über geplantem Aufwand liegen :: muss zwischen 1 und liegen :: geplanter Aufwand nicht negativ 215

104 Prüfung der Annotation mit JPA (1/2) public static void pruefebacklogelement() { Persistierer pers = new Persistierer("SprinterJSE"); BacklogElement b = new BacklogElement("HS", 42); pers.persist(b); Mitarbeit m1 = new Mitarbeit(30); Mitarbeit m2 = new Mitarbeit(30); m1.setbacklogelement(b); m2.setbacklogelement(b); pers.persist(m1); pers.persist(m2); b.addmitarbeit(m1); b.addmitarbeit(m2); 216

105 Prüfung der Annotation mit JPA (2/2) try { pers.merge(b); catch (Exception e) { // hier RollbackException ConstraintViolationException ctmp = (ConstraintViolationException) e.getcause(); System.out.println(ctmp.getMessage()); for (ConstraintViolation cv : ctmp.getconstraintviolations()){ System.out.println(":: " + cv.getmessage()); finally { pers.schliessen(); Bean Validation constraint(s) violated while executing Automatic Bean Validation on callback event:'preupdate'. Please refer to embedded ConstraintViolations for details. :: Backlog-Element: Verteilter Aufwand darf nicht über geplantem Aufwand liegen 217

106 Fazit JPA erleichtert die Zusammenarbeit von OO und DB wesentlich viele Annotationen, aber oft nur eingeschränkt benötigt, da Default-Einstellung meist für optimistisches Sperren nutzen Schlüssel einfach generieren lassen Wissen über SQL, Transaktionssteuerung und Nutzung von DB selbst, bleibt wichtig Nachträgliche Änderungen des Objektmodells müssen meist von Hand in Datenbanktabellen nachgezogen werden Vermeiden Sie (zumindest mit JEE) alle Trigger und Stored Procedures (System wird unwartbar) 218