Der Screenshot zeigt die Konfiguration für die Projektionen der Tupel-Suche:

• Die Feldprojektion liefert den Textwert im Feld "Benutzername" (username).
  
  

• Die Collection Projektion soll die zugewiesenen Rollen auflisten:
  
  

  • Als Feld für Join behalten wir den Standard "ID" (id) bei.
    
    

  • Als Feld der Collection wählen wir das Listenfeld "Rollen" (roles) aus, in dem das Benutzerkonto die zugewiesenen Rollen über deren ID-Werte (Long) referenziert.

►HINWEIS◄ Wir verzichten auf ausdrückliche Zuordnungen für den Parameter Name in beiden Projektionen, sodass die Feldnamen username und roles die Spalten identifizieren.

Das Ergebnis der Tupel-Suche (rechts) zeigt neben dem Textwert (username) einen Listenwert (roles), der für unterschiedliche Benutzer eine unterschiedlich umfangreiche Auswahl an Rollen über Long-Werte referenziert. Jedem Benutzer werden die ihm zugewiesenen Rollen zugeordnet.

►ANMERKUNG◄ Mehr Information zur Rolle bietet das Benutzerkonto selbst nicht an. Per Datenobjekt Join könnten Detaildaten der Rolle einbezogen und dann auch in der Collection Projektion per Feld der Collection berücksichtigt werden.

►HINWEIS◄ Das XML-Format verdeutlicht auch, dass die Reihenfolge der entry-Elemente für Listeneinträge "unsortiert" erscheinen. Tatsächlich besteht auch keine Möglichkeit zum Sortieren der in einer Collection-Spalte gesammelten Werte innerhalb der Abfrage. Bei Bedarf muss das Ergebnis also nachträglich aufbereitet werden, soweit möglich.

   <core:TupleSearchResult maxResults="100" count="43">
      <columns>
         <name>username</name>
         <name>roles</name>
      </columns>
      <result>
         <row>
            <item xsi:type="xsd:string">adent</item>
            <item xsi:type="list">
               <entry xsi:type="xsd:long">1401</entry>
               <entry xsi:type="xsd:long">501</entry>
            </item>
         </row>
         <row>
            <item xsi:type="xsd:string">Q</item>
            <item xsi:type="list">
               <entry xsi:type="xsd:long">1001</entry>
               <entry xsi:type="xsd:long">1</entry>
               <entry xsi:type="xsd:long">501</entry>
               <entry xsi:type="xsd:long">1201</entry>

               ...
            </item>
         </row>
         ...
      </result>
   </core:TupleSearchResult>

Der Screenshot rechts zeigt die Projektionen für eine Tupel-Suche:

• Die Feldprojektion gibt das Feld "Benutzername" (username) eines Benutzers (je Zeile) zurück.
  
  

• Die Collection Projektion bezieht sich auf dasselbe Feld "Benutzer" (username) per Feldprojektion im Parameter Feld der Collection.
  
  

• Als Feld für Join ist abweichend vom Standard das Feld "Besitzer" (ownerId) ausgewählt.
  
  

• Der Name "SAME_OWNER" weist auf den Inhalt der Collection hin.

Das Ergebnis der Tupel-Suche (rechts) zeigt neben dem Textwert (username) einen Listenwert (SAME_OWNER), der für unterschiedliche Benutzer die Name aller Benutzer angibt, für die die "Besitzer"-Firma des Benutzers ebenfalls als "Besitzer" gilt.

►HINWEIS◄ Wie die Beispieldaten veranschaulichen sollen, taucht der in der username-Spalte ausgegebene Benutzername zwangsläufig immer auch in der Collection auf. Das kann im Kontext der Collection Projektion auch nicht verhindert werden, da die Konfiguration neben dem Feld für Join keine Nebenbedingungen für die Zuordnung der gesammelten Daten vorsieht.

Allerdings kann die Collection Projektion durchaus verwendet werden, um zu erreichen, dass in der SAME_OWNER-Spalte nur andere Benutzernamen erscheinen, als der in der username-Spalte genannte. Wie das geht, zeigt das folgende etwa komplexere Beispiel.

   <core:TupleSearchResult maxResults="100" count="3">
      <columns>
         <name>username</name>
         <name>SAME_OWNER</name>
      </columns>
      <result>
         <row>
            <item xsi:type="xsd:string">bbanner</item>
            <item xsi:type="list">
               <entry xsi:type="xsd:string">pparker</entry>
               <entry xsi:type="xsd:string">bbanner</entry>
               <entry xsi:type="xsd:string">srogers</entry>
               ...
            </item>
         </row>
         <row>
            <item xsi:type="xsd:string">bwayne</item>
            <item xsi:type="list">
               <entry xsi:type="xsd:string">bwayne</entry>
               <entry xsi:type="xsd:string">ckent</entry>
               <entry xsi:type="xsd:string">acurry</entry>
               ...
            </item>
         </row>
      </result>
      ...
   </core:TupleSearchResult>

Da innerhalb der Collection Projektion keine beliebigen Bedingungen für die Zuordnung der gesammelten Daten formuliert werden können, müssen wir in unserer Suche einen Datenobjekt Join einrichten, der explizit dazu dient, die anderen Benutzer mit demselben Besitzer zu identifizieren.

Der Datenobjekt Join wird wie rechts abgebildet konfiguriert:

• Als Datenobjekt ist der Entitätstyp "Benutzer" ausgewählt.
  
  

• Als Join Alias wurde hier willkürlich das Kürzel u2 zugeordnet,
  
  

• Die Join Bedingung prüft zwei Kriterien in einer UND-Verknüpfung:
  
  

  • Die erste Feld Einschränkung (id!=u2.id) verhindert, dass der Haupt-Benutzer als u2-Benutzer zurückgegeben wird.
    
    Dieses Kriterium definiert die Nebenbedingung, die im vorherigen Beispiel innerhalb der Collection Projektion nicht konfiguriert werden konnte.
    
    

  • Die zweite Feld Einschränkung (ownerId==u2.ownerId) verlangt, dass alle u2-Benutzer denselben "Besitzer" haben müssen, wie der Haupt-Benutzer.
    
    Dieses Kriterium entspricht der Feldauswahl von "Besitzer" (ownerId) als Feld für Join in der Collection Projektion im vorherigen Beispiel.

Der Screenshot rechts zeigt, die Projektionen, mit denen das gewünschte Ergebnis erzielt werden kann:

• Die Feldprojektion für die username-Spalte kann unverändert beibehalten werden.
  
  

• Die Collection Projektion für die SAME_OWNER-Spalte verweist jetzt als Feld der Collection per Pfad u2.username auf das "Benutzername"-Feld der über den Datenobjekt Join (u2) einbezogenen Benutzer.
  
  

• Im Feld für Join muss der Standardwert "ID" (id) ausgewählt werden, da (1:n)-Beziehung nun durch den Datenobjekt Join entsteht.

Mit denselben Beispieldaten wie im vorherigen Beispiel, enthält die in der SAME_OWNER-Spalte ausgegebene Liste nun jeweils einen Eintrag weniger, weil der Haupt-Benutzer nun ausschließlich in der username-Spalte erscheint.

Das Ergebnis erscheint in einer CSV-Suche deutlich übersichtlicher:

username,SAME_OWNER

bbanner,[pparker, srogers, ...]
bwayne,[ckent, acurry, ...]
...

►HINWEIS◄ Auch in diesem Beispiel ist erkennbar, dass die Reihenfolge der Listeneinträge innerhalb des SAME_OWNER-Felds "unsortiert" wirkt. Es besteht keine Möglichkeit auf die Reihenfolge innerhalb der Collection Einfluss zu nehmen. Auch eine Sortierung nach der einer Feldprojektion wie u2.username ist nicht hilfreich. Im Gegenteil: Die Collection Projektion liefert weiterhin unsortiert und die Sortierung multipliziert die Ausgabezeilen (Benuzter x u2) obwohl im Datenobjekt Join (u2) die Option Optional ausgewählt ist (s. o.).

   <core:TupleSearchResult maxResults="100" count="3">
      <columns>
         <name>username</name>
         <name>SAME_OWNER</name>
      </columns>
      <result>
         <row>
            <item xsi:type="xsd:string">bbanner</item>
            <item xsi:type="list">
               <entry xsi:type="xsd:string">pparker</entry>
               <entry xsi:type="xsd:string">srogers</entry>
               ...
            </item>
         </row>
         <row>
            <item xsi:type="xsd:string">bwayne</item>
            <item xsi:type="list">
               <entry xsi:type="xsd:string">ckent</entry>
               <entry xsi:type="xsd:string">acurry</entry>
               ...
            </item>
         </row>
      </result>
      ...
   </core:TupleSearchResult>

Die rechts abgebildete Collection Projektion für die Listenspalte mit Name "CA_ACC_NUMBERS") greift über eine Feldprojektion mit dem im Parameter Feld für Join angegebenen Pfad ca.address.accNumber unmittelbar auf das "Kontonummer"-Feld jeder Firma zu, die der Datenobjekt Join (ca), dem jeweiligen Benutzerkonto zuordnet.

Die Collection zeigt mit dieser Konfiguration keine Hinweise auf Firmen, für die keine Angabe zur "Kontonummer" vorliegt.