Collection Projektion

Name

String

Der optionale Parameter Name kann verwendet werden, um der Projektion einen (Alias-)Namen zuzuweisen.

• Wenn kein Name angegeben ist, wird als Spaltenname (sofern relevant) der für das Feld der Collection anwendbare Name durchgereicht.

Feld für Join

String

(Auswahlfeld)

Das Feld für Join bestimmt über welches Feld die als Collection bereitgestellten Werte in den Kontext der Suche eingebunden werden sollen.

Der Parameter Feld für Join definiert einen Pfad zu einem Feld als Zeichenfolge, die per Direkteingabe oder Auswahl aus dem Dropdown festgelegt werden kann (Details s. Feldprojektion, Parameter "Feld").

Ohne Auswahl für das Feld für Join, wird das Feld "ID" (id) verwendet. Dieses Feld ist auch als Standardwert vorbelegt.

Feld der Collection

Projektion

Für den Parameter Feld der Collection können beliebige Projektionen eingesetzt werden. Die Projektion bestimmt, welche Werte gesammelt und dann über das Feld für Join im Kontext der Suche zugeordnet werden.

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.