Besser später als nie, hier also dann mal - nach laaaanger Zeit mal wieder - mein aktueller Status.
Mittlerweile bin ich ein ganzes Stück weiter und so fange ich sogar an, dem ganzen System von Persistence etwas abgewinnen zu können. Einzig die Frage bleibt, wieso JPA per default partout alle Feldnamen als groß schreibt. Naja das wird sich sicherlich auch noch klären. Aber zuersteinmal der Reihe nach:
Das - anfängliche Problem, dass ich ja einen Integer Primary Key brauche, aber auch zum Beispiel auch ein User Objekt anhand eines Namens (der ja nach meiner Definition auch eindeutig sein soll) erstellen will, ergab sich die Zwickmühle, dass es ein System geben muss, welche einem quasi einfache SQL Searches erlaubt... gibt es auch.
Anhand einer Präsentation, von Phillip fand sich dann auch eine recht kurze (und demnach schmerzlose) Lösung:
@Entity
@Table(name = "Users")
@NamedQuery(name = "findWithName", query = "SELECT u FROM User u WHERE u.name = :Name")
public class User {
....
}
Das sagt der Klasse, dass sie, wenn ich eine Query namens ("findWithName") ausführe, das nachfolgende SQL Statement benutzen soll und demnach auch den Parameter 'Name'
Der Aufruf schaut dann so aus:
User user = (User) em.createNamedQuery("findWithName").setParameter("Name", "TestUser").getSingleResult();
Nunja ein schöner, langer Aufruf. Aber immerhin wird mir ein User Objekt erstellt, wenn ein User mit Namen 'TestUser' existiert!
Kommen wir zum nächsten Punkt - mein Lieblingspunkt an diesem Morgen, weil das mich ziemlich viel Zeit und Schwei
zß gekostet hat (obwohls doch eigentlich so einfach ist) - die Kardinalitäten - ODER AUCH -" wie papern, wer n Eintrag an'nen User?"
Ich bin in mich gegangen und kam mit der Entscheidung aus mir (sagt man das so?), dass ich für jeden Eintrag, der von User A nach User B geschickt wird, ein Eintrag in der Datenbank erstellt wird. Also selbst, wenn User A an B und C die gleiche Aufgabe verteilen würde, würden zwei Einträge erstellt. Ich weiß, dass es dann recht unmöglich ist, zum Beispiel zwei User für eine Aufgabe vorzusehen und diese Aufgabe dann bei User B erledigt ist und bei User C noch offen - letztendlich ging es mir auch ersteinmal darum, die Abhängigkeiten hin zu bekommen.
Also erstmal die Veriante mit Stützrädern (zwei Tabellen) und dann hinterher (so morgen) schau ich mal, ob ich das auch freihändig schaffe (so drei Tabellen).
Letztendlich schaut das mit JPA ähnlich aus wie bei Willem und seinen RoR (gabs da nich mal n Lied mit RoR, RoR, RoR the Boat? aber ich glaube das war Row... egal).
Also vielleicht zuerst einmal die beiden Klassen und wie diese zusammenhängen:
Ja die Attribute laden quasi dazu ein, auf eine 3. Tabelle auszulagern ;-).
Es gibt also zwischen User und Entry exact zwei 1-zu-N Beziehungen:
1. Hat ein User genau eine Inbox mit N erhaltenen Entries
2. Hat ein User genau eine Outbox mit N versandten Entries
Da Willem nich Ruhe geben wollte, habe ich die Tabellen gleich mal Pluralisiert (okay ist auch sonst ne ganz gute Idee) und die IDs
_id getauft.
Für JPA geht man nun wie folgt vor:
...
public class User {
...
@OneToMany(mappedBy = "recipient")
private Collection inbox;
@OneToMany(mappedBy = "sender")
private Collection outbox;
...
}
...
sagt einem, dass jeweils die Attribute (eigentlich die Items aus den Collections) inbox und outbox an das Attribut (und hierbei geht es wohl wirklich um das Objekt ansich) "recipient"/ "sender" gemapped werden.
In der Klasse Entry muss dann natürlich quasi "das Kind konfiguriert werden" (das klingt jetzt seltsam aber im Moment fällt mir nix gescheiteres ein):
...
public class Entry {
...
@ManyToOne()
@JoinColumn(name="recipient_id")
private User recipient;
@ManyToOne()
@JoinColumn(name="sender_id")
private User sender;
...
}
...
Na gemerkt? ManyToOne anstatt OneToMany....ach war klar? Na,... okay :-).
Nun werden halt nur noch schnell die Feldnamen aus der DB Table angegeben und besagte Objekte erstellt ( "recipient"/ "sender" ). Geht ja eigentlich ganz schnell...
Das Setten/Getten probiere ich dann mal morgen und dann auch gerne mit 1+1+1 = 3 Tabellen. Gibt einem ja dann doch ein wenig mehr Möglichkeiten.
Das EJB3 Buch ist übrigens gut. Man liest, schreibt, sucht dann noch nen anderes Beispiel und dann versteht man es erst ;-). Nach und nachen rücken aber erster und letzter Schritt immer näher zusammen.
Ich wünsche allen eine erfolgreiche Woche.
