Entwicklung verschachtelter Beans für SQL-Abfragen mit Tabellenjoins

Sie können pureQuery-Annotationen in einer Gruppe verschachtelter Beans verwenden, um Gruppen von Beans zu erstellen, die Daten aus SQL-Abfragen mit Tabellenjoins zurückgeben. pureQuery Runtime generiert die Implementierung für die Gruppe verschachtelter Beans. Die Implementierung basiert auf den Tabellenjoins in den SQL-Anweisungen und den pureQuery-Annotationen, die zu den Beans hinzugefügt werden.

Sie erstellen die Gruppe verschachtelter Beans, die die hierarchische Datenstruktur der zurückzugebenden Daten definiert. Wenn Sie eine Annotation @JoinPoint für eine Bean-Eigenschaft angeben, die mit einer Spalte eines ResultSet-Objekts übereinstimmt, generiert pureQuery Runtime die entsprechende Implementierung. pureQuery Runtime analysiert die hierarchische Struktur der Bean der höchsten Ebene. Dies ist die Bean, die nach der Verarbeitung des ResultSet-Objekts und der verschachtelten Beans zurückgegeben wird. Es werden nur die Beans bzw. die Liste von Beans generiert und gefüllt, die durch eine Spalte eines ResultSet-Objekts aktualisiert wurden und die eine Annotation @JoinPoint haben. Beans bzw. Beanlisten, die nicht durch eine Spalte eines ResultSet-Objekts gefüllt werden oder die keine Annotation @JoinPoint haben, haben entweder den Wert Null oder den Initialisierungswert des Bean-Konstruktors.

Beispiel einer Gruppe verschachtelter Beans

Hier sehen Sie ein Beispiel mit zwei Beans. Die Bean der höchsten Ebene ist eine Department-Bean und die untergeordneten Beans sind eine Liste von Employee-Beans.

Das Beispiel nutzt die folgende SQL-Abfrage mit einem Join zwischen den Tabellen DEPARTMENT und EMPLOYEE. Die Abfrage hat einen Parameter, die Abteilungsnummer, und gibt alle Mitarbeiter zurück, die dieser Abteilung angehören:
Select D.DEPTNO, D.DEPTNAME, D.MGRNO, D.ADMRDEPT, E.EMPNO, E.FIRSTNME, E.MIDINIT, 
     E.LASTNAME, E.JOB, E.SEX, E.BIRTHDATE, E.SALARY 
   from (DEPARTMENT AS D LEFT JOIN EMPLOYEE AS E ON D.DEPTNO=E.WORKDEPT) 
   WHERE D.DEPTNO=? ORDER BY D.DEPTNO, E.LASTNAME
Die folgende DAO-Schnittstellenmethode gibt die SQL-Abfrage an:
  @Select(sql = "Select D.DEPTNO, D.DEPTNAME, D.MGRNO, D.ADMRDEPT, E.EMPNO, 
     E.FIRSTNME, E.MIDINIT, E.LASTNAME, E.JOB, E.SEX, E.BIRTHDATE, E.SALARY 
    from (DEPARTMENT AS D LEFT JOIN EMPLOYEE AS E ON D.DEPTNO=E.WORKDEPT) 
    WHERE D.DEPTNO=? ORDER BY D.DEPTNO, E.LASTNAME")
  public Department joinTest (String deptNo);

Die folgenden beiden Beans wurden für die SQL-Abfrage entwickelt. Die Bean 'Department' ist die Bean der höchsten Ebene, die nach der Verarbeitung der Ergebnismenge zurückgegeben wird. Die Bean 'Department' ist die übergeordnete Bean der Liste der deptEmployees-Beans. Die Liste von deptEmployees-Beans ist eine Gruppe untergeordneter Beans. Die Identitätsspalte, d. h. die Eigenschaft in einer Bean mit der Annotation @Id, ist deptNo.
@Table(name = "DEPARTMENT")
public class Department
{
  @Id
  @GeneratedKey
  public String deptNo; // this is the ID of the bean and its value is generated by the database
  public String deptName;
  public String mgrNo;
  public String admrDept;
  @JoinPoint(@JoinColumn(name = "EMPNO", table = "EMPLOYEE", propertyName = "empNo"))
  public List<Employee> deptEmployees;
} 
Die von der Liste von deptEmployees-Beans zurückgegebenen Daten werden von der Klasse 'Employee' definiert.
@Table(name = "EMPLOYEE")
public class Employee
{
  @Id
  @GeneratedKey
  public String empNo; // this is the ID of the bean and its value is generated by the database
  public String firstNme;
  public String midInit;
  public String lastName;
  public String workDept;
  public String job;
  public String sex;
  public java.sql.Date birthdate;
  public String salary;
}

pureQuery Runtime generiert Implementierungscode für die Beans basierend auf der SQL-Abfrage und den Beans.

Die zurückgegebenen Java-Objekte sind eine Bean 'Department', die ein Objekt java.util.List mit 11 deptEmployees-Beans enthält.

Die resultierende formatierte Ausgabe aus dem Aufruf der Methode joinTest("D11") sieht folgendermaßen aus. Die ersten vier Spalten sind die Daten aus der Bean 'Department'. Die anderen Spalten mit Mitarbeiterdaten stammen aus den deptEmployees-Beans:
dept                             admr                    mid
No  deptName              mgrNo  Dept empNo    firstNme  Init lastName  job      sex birthdate  salary
D11 MANUFACTURING SYSTEMS 000060 D01  000150   BRUCE          ADAMSON   DESIGNER M   1977-05-17 55280.00
                                      000200   DAVID          BROWN     DESIGNER M   1971-05-29 57740.00
                                      200220   REBA      K    JOHN      DESIGNER F   1978-03-19 69840.00
                                      000210   WILLIAM   T    JONES     DESIGNER M   2003-02-23 68270.00
                                      000220   JENNIFER  K    LUTZ      DESIGNER F   1978-03-19 49840.00
                                      000160   ELIZABETH R    PIANKA    DESIGNER F   1980-04-12 62250.00
                                      000180   MARILYN   S    SCOUTTEN  DESIGNER F   1979-02-21 51340.00
                                      000060   IRVING    F    STERN     MANAGER  M   1975-07-07 72250.00
                                      000190   JAMES     H    WALKER    DESIGNER M   1982-06-25 50450.00
                                      200170   KIYOSHI        YAMAMOTO  DESIGNER M   1981-01-05 64680.00
                                      000170   MASATOSHI J    YOSHIMURA DESIGNER M   1981-01-05 44680.00 

Typen von Beans in einer Gruppe verschachtelter Beans

Wenn Sie eine Gruppe verschachtelter Beans für SQL-Abfragen mit Tabellenjoins erstellen, werden die folgenden Typen von Beans erstellt:
Bean der höchsten Ebene
Die Bean der höchsten Ebene ist die Bean, die den Rückgabewert der Methode oder der integrierten API darstellt. Die Bean der höchsten Ebene muss mindestens eine @Id-Annotation haben, wenn sie mit pureQuery-Annotationen in einer Gruppe verschachtelter Beans verwendet wird. Als übergeordnete Bean muss sie auch mindestens eine @JoinPoint-Annotation enthalten. Die Bean kann eine übergeordnete oder eine untergeordnete Bean sein. In einigen Fällen kann eine Bean in derselben verschachtelten Struktur sowohl eine übergeordnete als auch eine untergeordnete Bean sein.
Übergeordnete Bean
Eine übergeordnete Bean muss mindestens eine @JoinPoint-Annotation enthalten, die auf eine Bean oder eine Liste von Beans, die untergeordneten Beans, verweist. Eine @Id-Annotation ist in einer übergeordneten Bean nur erforderlich, wenn es sich um eine Bean der höchsten Ebene handelt. Wenn eine übergeordnete Bean, z. B. BeanB, keine @Id-Annotationen enthält, muss sie auch eine untergeordnete Bean sein. Die übergeordnete Bean von BeanB, BeanA, muss @JoinColumn-Annotationen in einer @JoinPoint-Annotation enthalten. Die @JoinColumn-Annotationen in BeanA geben Identitätsspalten für deren untergeordnete Bean, BeanB, an.
Untergeordnete Bean
Der Verweis auf eine untergeordnete Bean erfolgt mit einer @JoinPoint-Annotation von ihrer übergeordneten Bean. Eine untergeordnete Bean muss nur dann eine @Id-Annotation enthalten, wenn sie auch eine Bean der höchsten Ebene ist. Wenn die untergeordnete Bean keine @Id-Annotation enthält, muss deren übergeordnete Bean die Identitätsspalten dieser Bean mit mindestens einer @JoinColumn-Annotation in einer @JoinPoint-Annotation angeben.

Identitätsspalten in einer Gruppe verschachtelter Beans

Beim Generieren und Füllen einer Gruppe verschachtelter Beans verwendet pureQuery Runtime die Annotation @JoinPoint beim Verweis auf die Bean im übergeordneten Element der Bean oder in der Annotation @Id der Bean selbst. Die Annotationen definieren die Identitätsspalten, die die untergeordneten Beans mit der übergeordneten Bean verknüpfen. pureQuery Runtime nutzt Identitätsspalten beispielsweise, um zu ermitteln, wann eine Liste von Beans für eine übergeordnete Bean zu generieren ist.

Eine Tabelle EMPLOYEE könnte z. B. mehrere Spalten enthalten, die Identitätsspalten sein könnten. Spalten, die als Identitätsspalte definiert werden könnten, sind die Personalnummer oder die Sozialversicherungsnummer des Mitarbeiters. Die Identitätsspalte kann der Primärschlüssel der Tabelle sein; sie muss jedoch kein Tabellenschlüssel sein. Mehrere Spalten können zu einem Verbundschlüssel kombiniert werden, ein Verbundschlüssel kann aber auch für eine Datenbanktabelle erstellt werden. Der Name wäre eine schlechte Wahl für eine Identitätsspalte der Tabelle EMPLOYEE, da Mitarbeiter denselben Namen haben könnten.

pureQuery Runtime nutzt die Informationen aus der Identitätsspalte und weitere Bean-Informationen bei der Verarbeitung des ResultSet-Objekts. Bei einer SQL-Abfrage mit Tabellenjoins könnten die Daten im ResultSet-Objekt die Datenzuordnung in einer hierarchischen Bean-Struktur erschweren. Im Folgenden sind einige Merkmale aufgeführt, die Probleme bei der Verarbeitung verursachen könnten:
  • Die Daten sind nicht sortiert.
  • Die Reihenfolge der Daten in den Datenbanktabellen muss möglicherweise beibehalten werden.
  • Daten sind im ResultSet-Objekt doppelt enthalten. Dies geschieht, wenn die Daten in der Datenbank Eins-zu-viele-Beziehungen enthalten. Beispielsweise hat Abteilung viele Mitarbeiter. Ein ResultSet-Objekt kann Daten aus einem Join zwischen einer Abteilungstabelle und einer Mitarbeitertabelle enthalten. Die Abteilungsinformationen werden für jeden Mitarbeiter in der Abteilung dupliziert.

pureQuery Runtime stellt sicher, dass die Beans mit der korrekten Datengruppe in der richtigen Reihenfolge gefüllt werden. Beispielsweise sind die ResultSet-Daten möglicherweise nicht so sortiert, dass sie sich genau der Struktur der verschachtelten Bean zuordnen lassen. pureQuery Runtime kann ResultSet-Daten verarbeiten, die zu Beans gehören, die früher in der Verarbeitung des ResultSet-Objekts erstellt wurden, und kann Beans mit den entsprechenden Daten in der richtigen Reihenfolge füllen.

Regeln für die Erstellung von Gruppen verschachtelter Beans

Sie können eine Gruppe verschachtelter Beans erstellen, die Ergebnisse aus SQL-Anweisungen mit komplexen Joinvergleichselementen zurückgeben, indem Sie eine komplexere Verschachtelungsstruktur mit den korrekten Annotationen erstellen. Zur Erstellung einer Gruppe von Beans, die die korrekten Ergebnisse zurückgeben, müssen die folgenden Regeln beachtet werden. Möglicherweise sind Änderungen an der SQL-Abfrage oder an den Beans erforderlich, damit eine sinnvolle Gruppe von Beans erstellt werden kann.

  1. Der Spaltenname jeder Spalte im ResultSet-Objekt muss einer einzigen Eigenschaft in der übergeordneten Bean oder in untergeordneten Beans zugeordnet werden.
    Anmerkung: Wenn mehr als eine Spalte einer bestimmten Eigenschaft zugeordnet wird und die Spalten immer dieselben Daten zurückgeben, ist diese Zuordnung kein Problem. Probleme können jedoch entstehen, wenn mindestens eine der Spalten einen Nullwert annehmen kann. Eine Spalte kann beispielsweise einen Nullwert aus einer SQL-Abfrage mit einem Tabellenjoin zurückgeben. Die Abfrage kann eine Klausel WHERE oder ON enthalten, die keinen übereinstimmenden Schlüssel zwischen den beiden Tabellen findet.

    Dieses Problem kann durch Angabe von Aliasnamen in der SQL-Abfrage behoben werden. In Beans, die mehrere Spalten enthalten, können auch @Column-, @Table- oder @JoinColumn-Annotationen mit dem Tabellennamen in den Eigenschaften angegeben werden.

  2. Wenn die Struktur der verschachtelten Beans mehrmals dieselbe Bean enthält, werden alle Verweise auf diese Bean nach der ersten Instanz ignoriert. Indem nur die erste Instanz verwendet wird, wird die Möglichkeit einer unendlichen Rekursion verhindert, wenn pureQuery Runtime die Gruppe verschachtelter Beans verarbeitet. Es gibt drei Möglichkeiten zum Erstellen mehrerer ähnlicher Beans: Verwenden Sie das optionale @JoinPoint-Element columnPrefix. Verwenden Sie eine Unterklasse der ursprünglichen Bean und Spaltenaliasnamen in der SQL-Abfrage. Verwenden Sie @JoinPoint- oder @JoinColumn-Annotationen.
  3. Das erforderliche @JoinColumn-Element name muss dem Basiseigenschaftsnamen in der untergeordneten Bean entsprechen. Wenn dies nicht der Fall ist, muss das optionale Element propertyName mit dem Namen der übereinstimmenden Basiseigenschaft in der untergeordneten Bean angegeben werden.

    Der Basiseigenschaftsname ist der Name einer Bean-Eigenschaft ohne Annotationen, die deren Zuordnung zum ResultSet-Objekt verändern. Bei einem Feld ist der Basiseigenschaftsname der Java-Variablenname. Bei einer get-, set- oder is-Methode ist dies der Methodenname ohne das Präfix get, set oder is und das erste Zeichen ist in Kleinbuchstaben geschrieben. Bei den folgenden Beispielen muss bei der ResultSet-Spaltenkennung WORKDEPT die Groß-/Kleinschreibung nicht beachtet werden.

    Im folgenden Beispiel mit der get-Methode muss beim Basiseigenschaftsnamen 'workDepartment' die Groß-/Kleinschreibung beachtet werden.
    @Column(name = "WORKDEPT")
    public String getWorkDepartment (); 

    Eine @JoinColumn-Annotation kann in einer @JoinPoint-Annotation in einer Bean oder einer Liste von Beans angegeben werden. In diesem Fall setzen die angegebenen Elemente name und table die Spaltenkennung und den optionalen Tabellennamen, die in den @Id-Annotationen der untergeordneten Bean definiert sind, sowie alle zugehörigen angegebenen @Column-Annotationen außer Kraft.

    Eine untergeordnete Bean kann mehrere @Id-Annotationen enthalten. In diesem Fall sollte das erforderliche Element name der Annotation @JoinColumn dem Basiseigenschaftsnamen in der untergeordneten Bean entsprechen. Wenn die Namen nicht übereinstimmen, muss das optionale Element propertyName mit dem Namen der übereinstimmenden Basiseigenschaft in der untergeordneten Bean angegeben werden.

    Wenn Sie das vorherige Beispiel so ändern, dass für EMPNO in der SQL-Abfrage der Aliasname EMPNUM definiert wird, ist das Element propertyName in einer @JoinColumn-Annotation nicht erforderlich. Die untergeordnete Bean hat nur eine @Id-Annotation und pureQuery Runtime ermittelt, welche Eigenschaft zugeordnet werden soll. Sie würden die folgende @JoinPoint-Annotation der Bean 'Department' ändern:
    @JoinPoint(@JoinColumn(name = "EMPNO", table = "EMPLOYEE", propertyName = "empNo"))
      public List<Employee> deptEmployees;
    Die Annotation @JoinPoint könnte folgendermaßen angegeben werden:
      @JoinPoint(@JoinColumn(name = "EMPNUM", table = "EMPLOYEE", propertyName = "empNo"))
       public List<Employee> deptEmployees;
    Wenn Sie die Identitätsspalte der untergeordneten Bean 'Employee' von empNo in workDept ändern wollen, geben Sie das Element PropertyName wie folgt an:
      @JoinPoint(@JoinColumn(name = "WORKDEPT", table = "EMPLOYEE", propertyName = "workDept"))
      public List<Employee> deptEmployees;
  4. Die Annotation @Table wird auf Klassenebene verwendet. Die Annotation gibt einen Standardtabellennamen an, der zu allen Eigenschaften hinzugefügt werden soll, für die kein Tabellenname angegeben ist. Der Tabellenname kann außer Kraft gesetzt werden, um eine Eigenschaft anzugeben, die mit einem beliebigen Tabellennamen übereinstimmt.
  5. Untergeordnete Beans benötigen keine @Id-Annotation, um als Teil der Gruppe verschachtelter Beans betrachtet zu werden. Die Annotation @JoinPoint kann die Identitätsspalten für die untergeordnete Bean angeben. Diese Angabe von Identitätsspalten über die Annotation @Id gilt nur für die übergeordnete Bean in diesem Aufruf.

    Eine untergeordnete Bean muss eine einzelne Bean oder eine Liste von Beans sein und die untergeordnete Bean muss die Annotation @JoinPoint enthalten. Die Annotation @JoinPoint muss sich in der Eigenschaft der übergeordneten Bean befinden, die die untergeordnete Bean bzw. Liste von Beans definiert.

  6. Jede Spalte im ResultSet-Objekt darf nur den korrekten Eigenschaften in der übergeordneten Bean und in den untergeordneten Beans zugeordnet werden.

    Ein Beispiel für diese Zuordnung ist eine Tabelle DEPARTMENT, die eine Spalte DEPTNO enthält, die ein Primärschlüssel ist, und eine Tabelle PROJECT, die ebenfalls eine Spalte DEPTNO enthält. Die Spalte DEPTNO der Tabelle PROJECT ist ein Fremdschlüssel für die Tabelle DEPARTMENT. Der Abgleich zwischen Spalten im ResultSet-Objekt und in den Eigenschaften wird standardmäßig anhand der Spaltenkennung durchgeführt. In diesem Beispiel könnte ein Join der Tabellen DEPARTMENT und PROJECT zwei Spalten ergeben, die eine Spaltenkennung DEPTNO haben. Wenn die Struktur der über- und untergeordneten Beans erfordert, dass diese Spalten unterschiedliche Informationen enthalten, können Sie Annotationen zu den Beans hinzufügen. Die Annotationen können die Spalten durch Verwendung des Tabellennamens eindeutig machen. Sie können auch die SQL-Anweisungen ändern, indem Sie einen Aliasnamen hinzufügen, um eine eindeutige Spaltenkennung zu erzeugen. Es ist jedoch in SQL-Abfragen mit einem Join üblich, dass nur eine Spalte zurückgegeben wird, wenn mehrere Spalten identische Daten enthalten würden. In diesem Fall wäre es zulässig, dass eine Spalte mehrere Eigenschaften aktualisiert.

    Mit DAO-Darstellungen (Data Access Object - Datenzugriffsobjekt) erhalten Sie folgendermaßen Warnungen, dass mehrere Eigenschaften von derselben Spalte aus dem ResultSet-Objekt aktualisiert werden:
    • Es wird eine Warnung generiert, die die generierten Methoden beschreibt, die dieselbe Spalte nutzen. Diese Warnung wird nach der Generierung der Implementierung angezeigt, wenn Sie mit IBM® Data Studio arbeiten. Die Warnung wird auch in die Generator-Protokolldatei geschrieben, sofern diese vorhanden ist, und die Tracestufe wird auf java.util.logging.Level.WARNING oder feiner gesetzt.
    • Das pureQuery-Dienstprogramm Generator erstellt einen Kommentarblock über dem ResultHandler-Objekt der generierten verschachtelten Bean. Der Kommentar zeigt, welche generierten Handler die ResultSet-Spalte nutzen. Er zeigt auch, welche ResultSet-Spalten nie genutzt werden.

    Mit der integrierten Darstellung erhalten Sie Warnungen, wenn mehrere Eigenschaften von derselben ResultSet-Spalte aktualisiert werden. Die Warnungen werden in der pureQuery Runtime-Protokolldatei protokolliert, sofern diese vorhanden ist, und die Tracestufe wird auf java.util.logging.Level.WARNING oder feiner gesetzt.

  7. Eine @JoinPoint-Annotation ist erforderlich, wenn eine untergeordnete Bean mit einer übergeordneten Bean verknüpft wird. Eine @JoinColumn-Annotation muss in der @JoinPoint-Annotation angegeben werden, außer wenn eine der folgenden Bedingungen zutrifft:
    • Die untergeordnete Bean oder Liste von Beans enthält mindestens eine @Id-Annotation, die die Identitätsspalten der untergeordneten Bean vollständig definiert.
    • Die Eigenschaften der Identitätsspalten der untergeordneten Bean (mit allen optionalen Spaltenkennungen und Tabellennamen) geben korrekt die Spalten für die SQL-Anweisung an, die zur Erstellung des ResultSet-Objekts ausgeführt wird. In diesem Fall kann einfach die Annotation @JoinPoint ohne Elemente angegeben werden.

Laufzeitverarbeitung verschachtelter Beans

Anhand der unten aufgeführten Schritte wird beschrieben, wie pureQuery Runtime eine Gruppe verschachtelter Beans verarbeitet, wenn die Objekte mit den Daten aus dem ResultSet-Objekt generiert werden.
  1. Das Parsing beginnt mit der zurückgegebenen Bean, der übergeordneten Bean der höchsten Ebene. Jede Eigenschaft der Bean wird untersucht, um zu ermitteln, ob diese Eigenschaft vom ResultSet-Objekt aktualisiert wird. Wenn eine Eigenschaft aktualisiert wird und eine @JoinPoint-Annotation enthält, wird die Eigenschaft untersucht, um zu ermitteln, ob sie auf eine Bean oder auf eine Liste von Beans verweist. Wenn die Eigenschaft auf eine Bean oder eine Liste von Beans verweist, wird die Bean zur Liste untergeordneter Beans für diese übergeordnete Bean hinzugefügt. Alle Eigenschaften in der übergeordneten Bean werden verarbeitet, bevor pureQuery Runtime gefundene untergeordnete Beans verarbeitet. Die Eigenschaften in einer Bean werden in einer nicht deterministischen Reihenfolge untersucht.
  2. Nachdem alle Eigenschaften in der übergeordneten Bean untersucht wurden, wird die Liste untergeordneter Beans geprüft. Wenn die Liste mindestens eine untergeordnete Bean enthält, wird die erste Bean in der Liste verarbeitet, als wäre sie eine übergeordnete Bean.
  3. Nachdem die erste untergeordnete Bean in der ursprünglichen übergeordneten Bean gefunden wurde und eine Liste von deren untergeordneten Beans erstellt wurde, verarbeitet pureQuery Runtime die nächste untergeordnete Bean der ursprünglichen übergeordneten Bean. Wenn eine weitere Bean vorhanden ist, wird sie wie im vorherigen Schritt beschrieben verarbeitet.

    Alle untergeordneten Beans der ursprünglichen übergeordneten Bean werden verarbeitet, bevor untergeordnete Beans verarbeitet werden, um zu ermitteln, ob sie ihrerseits untergeordnete Beans enthalten.

pureQuery Runtime kann ermitteln, ob eine Klasse untergeordneter Beans zum ersten Mal verarbeitet wird oder ob es rekursive Verweise in den Beans gibt. Wenn das pureQuery Runtime-Parsing der verschachtelten Bean-Struktur eine Bean erkennt, die bereits geparst wurde, wird das Parsing dieser untergeordneten Bean gestoppt.

Anmerkung: Eine übergeordnete Bean, die eine untergeordnete Bean mehrmals enthält, wird nicht unterstützt. In dieser Situation speichert pureQuery Runtime die Informationen nur in eine der untergeordneten Beans. Sie können eine Unterklasse mit eindeutigen Eigenschaftsannotationen der untergeordneten Bean angeben. Sie können auch das Element columnPrefix in der Annotation @JoinPoint der übergeordneten Bean für jede der doppelten Klassen verwenden.

Rekursive Verweise auf eine Bean wirken sich auch darauf aus, wie pureQuery Runtime die Eigenschaften von untergeordneten Beans füllt. Nur die erste Instanz der Bean wird gefüllt. Spätere Verweise auf diese Bean werden ignoriert, es sei denn, der Verweis enthält eine Annotation @JoinColumn, für die ein anderes columnPrefix-Element definiert ist. Da die Verarbeitungsreihenfolge von Eigenschaften in einer einzigen Bean nicht deterministisch ist, werden auch die untergeordneten Beans in nicht deterministischer Reihenfolge verarbeitet. Die untergeordneten Beans werden jedoch in der Reihenfolge der Verschachtelungsebene verarbeitet. Beispielsweise wird eine Bean, die direkt unter der übergeordneten Bean angeordnet ist, vor einer Bean auf der nächsten Verschachtelungsebene verarbeitet.

Informationen zum Element columnPrefix finden Sie in der Dokumentation zur Annotation @JoinPoint.


Feedback