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
Literatur JSR 338: Java TM Persistence 2.1 http://jcp.org/en/jsr/detail?id=338 (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), 2006 114
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
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
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) http://www.oracle.com/technetwork/java/javadb/overview /index.html 117
Beispiel (1/7) package jpa20beispiel1; import javax.persistence.entity; import javax.persistence.id; @Entity public class Mitarbeiter { @Id 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
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="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_0.xsd"> <persistence-unit name="jpa20beispiel1pu" transaction-type="resource_local"> <provider> org.eclipse.persistence.jpa.persistenceprovider </provider> <class>jpa20beispiel1.mitarbeiter</class> 119
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
Beispiel (4/7) 121
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
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
Beispiel (7/7) Falls keine Tabelle Mitarbeiter existiert, wird diese angelegt 124
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
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
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
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
Primary Key Typisch: Primary Key wird erzeugt @Id @GeneratedValue(strategy = 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
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
Persistent Fields / Properties Persistent Fields @Id private int minr; Exemplarvariablen direkt annotiert Zugriff des Persistence-Frameworks direkt auf Variablen Vorteil: Variable und Annotation stehen direkt zusammen Persistent Properties @Id 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
Annotationen zur Flexibilisierung / Ergänzung @Entity @Table(name="Chef") public class Mitarbeiter implements Serializable { private static final long serialversionuid = 1L; @Id @GeneratedValue(strategy = GenerationType.AUTO) private int minr; @Column( name="leiter", nullable=false,updatable=true, unique=true) private String name;... 132
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
Beispiel für Cache (1/2) @Entity public class Mitarbeiter implements Serializable { @Id @GeneratedValue private int minr; @Column(length=2) //maximal zwei Zeichen private String name; public Mitarbeiter() { //parameterloser Konstruktor benötigt public Mitarbeiter(String name) { this.name = name; // get- und set-methoden weggelassen @Override public String tostring(){ return name+"("+minr+")"; 134
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]: 2010-03-28 13:12:57.868-UnitOfWork(20290587)- 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
Lebenslauf eines Entity-Objekts NEW -> merge() führt evtl. zur Mehrfachobjekterzeugung refresh() nur, wenn vorher persistiert 136
Lebenslaufanalyse (1/13) - Beispielentität @Entity public class Mitarbeiter2 implements Serializable { private static final long serialversionuid = 1L; @Id @GeneratedValue(strategy = 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 = name; @Override public String tostring() { return "["+this.id+": "+this.name+"]"; //... 137
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"/>... 138
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Ausschnitt 160
Datenmodell 161
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 geschrieben @OneToOne: Zuordnung zu (maximal) einem Objekt @OneToMany: Zuordnung von beliebig vielen Objekten (steht typischerweise bei Collections) @ManyToOne: Zuordnung zu einem Objekt (kann selbst mehrfach zugeordnet sein, steht, wenn benötigt, auf anderer Seite der @OneToMany-Beziehung @ManyToMany: Zuordnung von beliebig vielen Objekten, die auch wahrscheinlich in die Rückrichtung genutzt wird 162
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
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
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 sichern @OneToMany(mappedBy = "backlogelement") private List<Mitarbeit> mitarbeiten; 165
Wichtige Annotationen in Großprojekten @Version 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 ergänzen @Basic(fetch=FetchType.LAZY) 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
Umsetzung des Beispiels (1/9): Klassendiagramm 167
Umsetzung des Beispiels (2/9): BacklogElement @Entity public class BacklogElement implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) private long id; @Version private int version; @Length(min=1) private String titel; private int geplanteraufwand; @OneToMany( mappedby = "backlogelement", fetch = FetchType.EAGER) private List<Mitarbeit> mitarbeiten; @Enumerated(EnumType.STRING) private Phase phase; Werte als Strings, nicht Ordnungsnummern, speichern (besser bei Änderungen) 168
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 = text; @Override public String tostring() { return this.text; 169
Umsetzung des Beispiels (4/9): Mitarbeit @Entity public class Mitarbeit implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) private long id; @Version private int version; private int geplantestunden; private int verbrauchtestunden; private int fertigstellungsgrad; private String taetigkeit; @ManyToOne private Mitarbeiter mitarbeiter; @ManyToOne private BacklogElement backlogelement; 170
Umsetzung des Beispiels (5/9): Mitarbeiter @Entity public class Mitarbeiter implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) private long id; @Version private int version; @Column(unique = true) private int minr; private String name; @OneToMany(mappedBy = "mitarbeiter", fetch = FetchType.EAGER) private List<Mitarbeit> mitarbeiten; 171
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
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
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
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
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
Cascade-Varianten @OneToMany(cascade={CascadeType.PERSIST, 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 bei @OneToOne und @OneToMany 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
Weitere interessante Annotationen / Attribute Variable wird nicht persistiert @Transient zur Nutzung von java.util.date @Temporal(TemporalType.DATE) private Date starttermin; zur Sicherstellung der Reihenfolge @OrderColumn(name="Ord") private List<Mitarbeiter> mitarbeiter = new ArrayList<>(); bei Existenzabhängigkeit, Löschen der abhängigen Objekte @OneToMany(cascade = {CascadeType.ALL, orphanremoval=true) einfache Nutzung von Vererbung (drei Varianten) @Inheritance(strategy=InheritanceType. SINGLE_TABLE) @Inheritance(strategy=InheritanceType.JOINED) @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) 178
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
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
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
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
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
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
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
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
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
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 84 40 [Ljava.lang.Object;@2c1ec049 :: [Ljava.lang.Object; Basisdienste 84 40 [9 Ergebnisse] 188
Named Queries (1/2) @Entity @NamedQueries({ @NamedQuery(name = "BacklogElement.findAll", query = "SELECT o FROM BacklogElement o"), @NamedQuery(name = "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
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
Ungeordnete Daten (1/4) @Entity public class Punkt implements Serializable{ @Id @GeneratedValue private int id; private int x; private int y; @Version private int version; public Punkt(int x, int y) { this.x = x; this.y = y; public Punkt(){ @Override public String tostring(){ return "["+x+","+y+"]"; // get- und set-methoden für Exemplarvariablen Problem: Auch Listen werden ungeordnet gespeichert 191
Ungeordnete Daten (2/4) @Entity public class Polygon implements Serializable{ @Id @GeneratedValue private int id; @OneToMany(cascade = {CascadeType.ALL) private List<Punkt> punkte= new ArrayList<Punkt>(); @Version private int version; public Polygon(){ //get und set für Exemplarvariablen public void punktehinzu(punkt... pkte){ for(punkt p:pkte) punkte.add(p); @Override public String tostring(){ StringBuffer erg=new StringBuffer("<"); for(punkt p:punkte) erg.append(p.tostring()); return erg.append(">").tostring(); 192
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
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
Ordnung beibehalten @Entity public class Polygon implements Serializable{ @Id @GeneratedValue private int id; @OneToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE) @OrderColumn(name="Ord") private List<Punkt> punkte= new ArrayList<Punkt>(); @Version 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
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
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
Löschfortsetzung Anmerkung: auch keine Löschung alleine durch CASCADETYPE.ALL in Polygon, aber durch folgende Ergänzung @OneToMany(cascade = {CascadeType.ALL, @OrderColumn(name="Ord") 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
Vererbung eine Tabelle (1/3) @Entity public class Produkt implements Serializable { @Id @GeneratedValue private int prnr; private String name; private int lagermenge; private float preis; @Version private int version;... @Entity public class Lebensmittel extends Produkt implements Serializable{ @Temporal(javax.persistence.TemporalType.DATE) private Date verfallsdatum;... @Entity public class Buch extends Produkt{... 199
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 2009 200
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
Vererbung getrennte verknüpfte Tabellen @Entity @Inheritance(strategy=InheritanceType.JOINED) public class Produkt implements Serializable {... SELECT * FROM Produkt SELECT * FROM Lebensmittel SELECT * FROM Buch 202
Vererbung getrennte Tabellen @Entity @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) public class Produkt implements Serializable {... SELECT * FROM Produkt SELECT * FROM Lebensmittel SELECT * FROM Buch 203
Überwachungsmethoden (1/3) @Entity public class Mitarbeiter { @Id @GeneratedValue(strategy=GenerationType.AUTO) private int minr; private String name; private void p(string s){system.out.println(s); @PrePersist public void prepersit() {p("prepersist"); @PostPersist public void postpersist() {p("postpersist"); @PreRemove public void preremove() {p("preremove"); @PostRemove public void postremove() {p("postremove"); @PreUpdate public void preupdate() {p("preupdate"); @PostUpdate public void postupdate() {p("postupdate"); @PostLoad public void postload() {p("postload"); // Hinweis: Rollback bei einer Runtime Exception... 204
Ü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
Ü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
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 nutzbar Query-Builder @Lob @Column(name="PIC") private byte[] picture; @ManyToMany @JoinTable(name="PROJEKTROLLEN,joinColumns=@JoinColumn(name= ROLLEN_ID"),inverseJoinColumns=@JoinColumn(name="PROJ_ID")) 207
Einbindung von Bean-Validation Annotationen wie @Column 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
Validierung von Mitarbeiter public class Mitarbeiter implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) private long id; @Version private int version; @Column(unique = true) @Min(value=0, message="mitarbeiternummer nicht negativ") private int minr; @NotNull(message="Mitarbeitername muss angegeben werden") @Size(min=1, message="name darf nicht leer sein") private String name; @OneToMany(mappedBy = "mitarbeiter", fetch = FetchType.EAGER) @Valid private List<Mitarbeit> mitarbeiten; 209
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; import validation.validator.backlogelementvalidator; @Target({ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Constraint(validatedBy = BacklogElementValidator.class) @Documented public @interface BacklogElementCheck { String message() default "Aufwandsverteilung " + "bei BacklogElement beachten"; Class<?>[] groups() default {; Class<? extends Payload>[] payload() default {; 210
Erinnerung (2/3): eigene Validierungsannotation public class BacklogElementValidator @Override implements ConstraintValidator <BacklogElementCheck,BacklogElement> { public void initialize(backlogelementcheck anno) { // hier Zugriff auf Attributswerte der Annotation @Override public boolean isvalid(backlogelement value int verteiltearbeit = 0;, ConstraintValidatorContext context) { for(mitarbeit m: value.getmitarbeiten()){ verteiltearbeit += m.getgeplantestunden(); 211
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
Nutzung der Annotation @BacklogElementCheck @Entity public class BacklogElement implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) private long id; @Version private int version; @Length(min=1) private String titel; @Min(value=0, message = "geplanter Aufwand nicht negativ") private int geplanteraufwand; @OneToMany(mappedBy = "backlogelement") @Valid private List<Mitarbeit> mitarbeiten; @Enumerated(EnumType.STRING) private Phase phase; 213
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
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 2147483647 liegen :: geplanter Aufwand nicht negativ 215
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
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
Fazit JPA erleichtert die Zusammenarbeit von OO und DB wesentlich viele Annotationen, aber oft nur eingeschränkt benötigt, da Default-Einstellung meist passen @Version für optimistisches Sperren immer @NamedQueries 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