SPQL

Beschreibung

SQPL ist eine Sprache zur Beschreibung von Suchabfragen, sog. Queries, an den IES. Die Syntax ist ähnlich der Syntax von SQL und in einigen Teilen eine Untermenge hiervon.

Suchabfragen stellen Teilmengen der Daten zur Verfügung, die sich in der Datenbank des InfoSite5-Systems befinden. Diese Teilmengen lassen sich durch das zur Suchabfrage gehörige Query spezifizieren: Eine Query kann etwa alle Informationen zu einem Schlagwort suchen. Die Suchabfrage stellt dann diese Informationen aus den gefundenen Artikeln als Trefferliste zur Verfügung. Eine Query kann z.Z. auf Artikel, Nutzer oder Templates abgesetzt werden.

Syntax

Der Query-String hat dabei die folgende Syntax:

from ElementType where query [order by FieldName [asc|desc] limit [Offset] Limit

Für Suchabfragen auf Artikel kann der Teil "from ElementType where" weggelassen werden. Er ist implizit. Für die Suche nach anderen Elementen müssen die entsprechenden Element-Typen verwendet werden.

Element-Typen

Über den ElementType kann man steuern, ob eine Query auf Artikel, Nutzer oder Templates erfolgen soll. Folgende Schlüsselwörter müssen hierzu verwendet werden:

• information
• user
• template

Obwohl für eine Query nach Artikeln auf die Anweisung "from information where" verzichtet werden kann, sollte die genau Syntax verwendet werden.

Daten-Typen

Eine Query erlaubt in der Definition die Verwendung folgender Datentypen für die Abfragen entsprechender Felder:

Texte

wird angegeben durch Anführungszeichen (") bzw. (')

z.B. sp_headline = 'welcome'

Zahlen

wird ohne Anführungszeichen angegeben

z.B. sp_number > 49

ID's

werden ebenfalls ohne Anführungszeichen, jedoch mit Typ angegeben

z.B. createdBy = 100010100000000001-3001

Anker

werden auch ohne Anführungszeichen, jedoch mit den Anker-Klammern !{} angegeben

z.B. parent = !{pool_x}

Operationen

Für die Definition einer Query stehen folgende Operationen und Vergleiche zur Verfügung. Diese können je nach Datentyp eingesetzt werden, um das Suchergebnis entsprechend einzuschränken.

=

Findet alle Elemente, deren Feldinhalt gleich dem angegebenen Wert ist

!=

Findet alle Elemente, deren Feldinhalt ungleich dem angegebenen Wert oder gar nicht vorhanden ist

>

Findet alle Elemente, deren Feldinhalt (i.d.R. numerisch) größer als der angegebene Wert ist

<

Findet alle Elemente, deren Feldinhalt (i.d.R. numerisch) kleiner als der angegebene Wert ist

>=

Findet alle Elemente, deren Feldinhalt (i.d.R. numerisch) größer als bzw. gleich dem angegebenen Wert ist

<=

Findet alle Elemente, deren Feldinhalt (i.d.R. numerisch) kleiner als bzw. gleich dem angegebenen Wert ist

like

Findet alle Elemente, deren Feldinhalt ähnlich dem angegebenen Suchwort sind (hier gilt die reguläre SQL-Syntax). Der Vergleich findet auf Text-Inhalte statt und das Vergleichswort erlaubt folgende "Wildcards":

%

Entspricht einem oder mehreren beliebigen Zeichen ('abcde' = 'ab%e')

_

Entspricht einem beliebigen Zeichen ('abcde' = 'a_c_e')

not like

Findet alle Elemente, auf die ein angegebenes Vergleichswort NICHT zutrifft

range

Findet bei nummerischen Vergleichen Elemente, deren Feldinhalt zwischen zwei angegebenen Zahlen liegt (z.B. findet "sp_number range 0-9" alle Elemente, deren Feldinhalt von "sp_number" zwischen 0 und 9 liegt). Logisch entspricht die Range-Operation folgender Anweisung, ist aber deutlich schneller: "sp_number >= 0 AND sp_number < 9"

in

Der IN-Operator erlaubt die Übergabe von Listen, mit denen ein Feldinhalt verglichen wird. Es sind sowohl Texte, als auch Zahlen oder Anker zulässig ('a','b','c') oder (1,2,3) oder (!{a},!{b}). Leerzeichen zwischen den Elementen sind nicht erlaubt.

not in

Findet alle Elemente, deren Feldinhalte nicht mit den übergebenen Listen übereinstimmen

Logische Operationen

Eine Query läßt sich durch Verwendung logischer Operationen aus mehreren Teilen zusammenfügen. Dadurch läßt sich die Ergebnismenge i.d.R. auf die gewünschte Menge einschränken. Zur Steuerung der logischen Verknüpfung von mehreren Teilen einer Query können einfache, runde Klammern verwendet werden. Es stehen folgende Operanten zur Verfügung:

AND

Verknüpft zwei Anweisungen logisch UND

OR

Verknüpft zwei Anweisungen logisch ODER

NOT

Negiert eine Anweisung

( )

Durch die Verwendung von Klammern können die einzelnen Anweisungen verschachtelt bzw. gesteuert werden

Content-Typen

Eine Query wird i.d.R. über die Inhaltsfelder von Elementen abgesetzt. Da die Inhalte unterschiedlichen Typs sind, können bzw. müssen diese bei der Definition entsprechend angegeben werden. Die einzelnen Content-Typen sind in drei Gruppen unterteilt: TextContent, SystemContent und LinkContent. Der Zugriff erfolgt analog zu den Bezeichungen in den Templates, in SPML. Ebenso gilt: Ist kein bestimmter Typ angegeben, so wird der Typ text angenommen.

Der Zugriff erfolgt duch Angabe des Feldnamens ergänzt durch einen Punkt mit anschließender Angabe des Content-Typs.

feldname.content-typ

TextContent

Folgende Content-Typen sind als TextContent deklariert. Der Zugriff erfolgt über diese Schlüsselwörter

text

Dieser Typ ist implizit, kann jedoch auch angegeben werden

SystemContent

Folgende Content-Typen sind als SystemContent deklariert. Der Zugriff erfolgt über diese Schlüsselwörter

width

Zugriff auf die Breite von Bildern

height

Zugriff auf die Höhe von Bildern

mime

Zugriff auf den MIME-Type

format

Zugriff auf das Format von Medien

size

Zugriff auf die Dateigröße

LinkContent

Folgende Content-Typen sind als LinkContent deklariert. Der Zugriff erfolgt über diese Schlüsselwörter

link

Zugriff auf Links vom Typ link

systemlink

Zugriff auf Links vom Typ systemlink

navlink

Zugriff auf Links vom Typ navlink

keywordlink

Zugriff auf Links vom Typ keywordlink

categorylink

Zugriff auf Links vom Typ categorylink

CalendarContent

Der Zugriff auf Termine bzw. CalendarContent erfolgt ebenfalls über die hier bereits beschriebenen Mechanismen. Da Termindaten als nummerische Werte gespeichert werden, erfolgt die Auswertung dieser Inhalte ebenfalls über nummerische Operationen. Der Zugriff erfolgt über das Schlüsselwort

calendar

Zugriff auf Termin-Daten

Eine Query nach Terminen wird i.d.R. über einem Zeitpunkt bzw. einem Zeitraum definiert. Gefunden werden damit alle Elemente, deren Termine genau am, bzw. zwischen den angegeben Zeiten liegen. Folgende Beispiele verdeutlichen typische Abfragen auf Termindaten

Diese Query findet alle Elemente, deren Termine zwischen den angebenen Werten liegen

feldname.calendar > 123345789 AND feldname.calendar < 1234567890

Diese Query findet die gleichen Ergebnisse, ist jedoch performanter, da nur eine Abfrage ausgewertet werden muss (Entspricht: "x <= calendar < y")

feldname.calendar range 123345789-1234567890

Diese Query findet alle Termine für Feldname "dateItem" ab x

dateItem.calendar > 123345789

Diese Query findet alle Termine für Feldname "dateItem" vor x

dateItem.calendar < 123345789

Diese Query findet alle Termine für Feldname "dateItem" bis x

dateItem.calendar <= 123345789

Wildcards

Wildcards sind sog. Joker und dienen als Platzhalter für unterschiedliche Zeichen oder Zeichenketten. Bei der Definition von Suchabfragen kann neben den SQL-Wildcards auch noch das * verwendet werden, um über alle Feldnamen zu suchen. Folgende Wildcards können in Suchabfragen verwendet werden:

*

Kann verwendet werden wenn der Feldname über den gesucht werden soll nicht genau angegeben werden kann. Das Wildcard steht lediglich für den Feldnamen. Content-Typen wie "systemlink" (s.u.) müssen explizit angegeben werden

z.B. (* = 'inhalt a') OR (*.systemlink != !{artikel_x})

%

Steht für beliebig viele Zeichen im Suchwort

z.B. sp_headline = 'welcome %'

_

Steht für genau ein Zeichen im Suchwort

z.B. sp_rubric = 'section _a'

Schlüsselwörter

Weiterhin werden folgende Schlüsselwörter für die Definition einer Query bereitsgestellt

parent

Suche nach Elementen, deren Pool dem angegeben Wert entspricht

root

Suche nach Elementen, deren Pool unterhalb des angegebenen Root-Pools liegt

z.B. root = !{gui.informations}

Definierte Felder von Elementen

Je nach Element-Typ kann über unterschiedliche Attribute bzw. Felder gesucht werden. Für die Definition innerhalb einer Query werden entsprechende Schlüsselwörter verwendet, die i.d.R. analog zu den bekannten Bezeichnungen der SPML sind.

Attribute des Typs information

Für die Suche nach Artikeln stehen für die Suche neben den Inhalts-Feldern noch folgende Schlüsselwörter für die Attribute zur Verfügung

changed

Suche nach Änderungsdatum

changedBy

Suche nach Artikeln, die bestimmter Redakteur zuletzt geändert hat

comment

Suche über das Kommentarfeld

created

Suche nach Erstellungsdatum

createdBy

Suche nach Artikeln, die ein bestimmter Redakteur erstellt hat

directory

Suche über das Arbeitsverzeichnis

filename

Suche über den Dateinamen

name

Suche über den Artikelnamen

suffix

Suche über die Dateiendung

type

Suche über den Artikeltyp (Resource, Medium, eigene Seite)

Attribute des Typs template

Für die Suche nach Templates stehen für die Suche neben den Inhalts-Feldern noch folgende Schlüsselwörter für die Attribute zur Verfügung

comment

Suche über das Kommentarfeld

name

Suche über den Templatenamen

source

Suche über den Source-Code des Templates

type

Suche über den Typ des Templates

Attribute des Typs user

Für die Suche nach Nutzern stehen für die Suche neben den Inhalts-Feldern noch folgende Schlüsselwörter für die Attribute zur Verfügung

comment

Suche über das Kommentarfeld

email

Suche über die Email

firstname

Suche über den Vornamen

lastname

Suche über den Nachnamen

login

Suche über das Login

type

Suche über den Typ des Templates

Order By

Für nummerische Werte (Daten und Zahlen) kann optional in der Query ein order by verwendet werden. Das kann in Verbindung mit der limit-Anweisung sinnvoll sein, um frühzeitig die Treffermenge einzuschränken. INsbesondere für Listen die zuletzt geänderte Artikel finden soll. Ohne diese Einschränkungen würden zunächst alle Artikel geladen und müssten anschließend sortiert und gefiltert werden.

Optional kann auf die Sortierung noch über die Schlüsselwörter asc (=aufsteigend) und desc (=absteigend) Einfluss genommen werden.

Eine Sortierung von Zeichenkette kann zwar zum gewünschten Ergebnis führen, sollte aber nicht verwendet werden, da die alphanummerische Sortierung der Datenbank Anwendung finden würde. Und diese unterscheidet sich von der Sortierung im IES. Normale Suchabfragen sollten über Kriterien entsprechend eingeschränkt und anschließend über die Tags <sp:sort>, <sp:filter> und <sp:range> bearbeitet werden.

Generell kann nach folgenden Feldern sortiert werden:

created

Sortierung nach dem Datum der Erstellung

changed

Sortierung nach den Datum der letzten Änderung

alle Variablen vom Typ TextContent und SystemContent

Die Typen CalendarContent und LinkContent werden z.Z. noch nicht unterstützt

name

Sortierung nach dem Namen (Achtung: kein nummerischer Wert)

Limit

Über ein Limit kann die Treffermenge bereits auf SQL-Ebene frühzeitig eingeschränkt werden. Dies macht i.d.R. nur Sinn, wenn vorher ein order by angewandt wurde.