Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht
Navigation: Dokumentationen agorum core > agorum core JavaScript-API > agorum core smart search
Wichtig: Schreiben Sie Metadaten in Ihrem Suchstring stets klein, unabhängig von der eigentlichen Groß- und Kleinschreibung der Metadaten.
Jedes Feld wird automatisch „tokenized“. So wird etwa die E-Mail-Adresse unterteilt in einzelne Worte, basierend auf Trennzeichen.
Getrennt wird etwa beim @ und beim Punkt (.).
marta.mueller@agorumcore.com
marta, mueller, agorumcore, com
So indiziert und sucht das System wieder.
Suchen Sie etwa nach agorum.com, wird daraus intern:
agorum AND com
Sie können Suchen (Queries) mit AND oder OR verbinden:
Und-Suche, alle Such-Teile müssen einen Treffer erzeugen. AND ist die Standardeinstellung in agorum core. Dies bedeutet, dass eine explizite Angabe von AND nicht notwendig ist.
Beispiel
Suchbegriff | Beschreibung |
---|---|
agorum core | Hier werden beide Worte gesucht, d. h. agorum AND core, wobei das AND nicht geschrieben werden muss. |
Oder-Suche, nur ein Such-Teil muss einen Treffer erzeugen
Besitzt ein Query Klammern, so wird zuerst der Inhalt der Klammer geprüft und dann der Rest.
Hochkommas legen die Reihenfolge der Wörter fest, in denen diese im Objekt vorkommen sollen.
Suchbegriff | Beschreibung |
---|---|
agorum core | Zeigt alle Dokumente an, in denen die Wörter agorum und core vorkommen. Reihenfolge und Abstand zueinander spielen keine Rolle. |
„agorum core“ | Zeigt alle Dokumente an, in denen die Wörter agorum core vorkommen, und zwar in genau dieser Reihenfolge und ohne Wörter oder Zeichen dazwischen. |
Klammern werden wie in der Mathematik verwendet. Sie dienen dazu, Filteroptionen zu sortieren und eine Reihenfolge zu erstellen.
Suchbegriff | Beschreibung |
---|---|
abc (123 OR 456) |
|
Wörter, Metadaten oder Zahlen können ausgeschlossen werden.
Suchbegriff | Beschreibung |
---|---|
agorum NOT core | agorum, aber nicht core soll in einem Objekt vorhanden sein. |
Platzhalter (*, ?) dienen als eine Art „Lückenfüller“. Das ? wird verwendet, wenn man sich bei einem Buchstaben nicht sicher ist, während das * für beliebig viele Buchstaben (>=0) steht.
Suchbegriff | Treffer |
---|---|
agoru?m | agoru?m wird zu keinem Treffer führen, da ein Charakter / Zeichen anstelle des Fragezeichens vorhanden sein muss. |
agoru*m | agoru*m wird zu Treffern führen, da das Sternchen von beliebig vielen Zeichen ersetzt werden kann. |
Achtung: Beeinträchtigung der Systemleistung durch Verwendung des Platzhalters * am Anfang eines Wortes. Verwenden Sie den Platzhalter * nur in der Mitte oder am Ende eines Suchbegriffes, da das System ansonsten zu lange lädt und währenddessen langsamer arbeitet.
Für viele Suchanwendungen ist es nicht nur wichtig, den genauen Text zu finden, sondern sich an mögliche Rechtschreibfehler oder Variationen an Schreibmöglichkeiten anzupassen. Solr kann Character-Variationen anhand einer Edit-Distance erlauben. Dabei wird ein Suchbegriff verwendet und mit einer Tilde (~) am Ende die Anzahl an möglichen Variationen gekennzeichnet.
Suchbegriff | Treffer |
---|---|
administrator~ | adminstrator, administrator, administratar, administratior, … |
Die Tilde steht dabei für ein Suchergebnis, das den originalen Suchbegriff als auch Wörter mit 2 Edit-Distanzen erlaubt. Edit-Distanzen können dabei folgende Unterschiede sein:
Unterschied | Beschreibung | Beispiel |
---|---|---|
Insertion | Ein zusätzlicher Charakter wird in einem mit Suchergebnis eingebaut. | administratior |
Deletion | Ein Charakter wird aus dem Suchbegriff entfernt. | |
Substitution | Ein Charakter wird ausgetauscht. | adninistrator |
Transposition | Zwei Charaktere werden verdreht. | administatro |
Möchten Sie nur eine Edit-Distance oder beliebig viele erlauben, greifen folgende Schreibarten:
Schreibart | Beschreibung |
---|---|
administrator~1 | Nur eine Abweichung ist erlaubt. |
administrator~2 | Standard: administrator~ |
administrator~N | Beliebig viele Abweichungen sind erlaubt. |
Achtung: Beeinträchtigung der Systemleistung durch eine Edit-Distance >2. Arbeiten Sie stets mit maximal zwei Edit-Distanzen, da das System ansonsten zu lange lädt und währenddessen langsamer arbeitet.
Ähnlich wie bei der Fuzzy / Edit-Distance Searching sind bei dieser Suche Variationen der Suchbegriffe erlaubt. Anstatt Änderungen in einem Wort abzufangen, geht es hierbei um Änderungen in einer Wörterkette.
Suchbegriff | Beschreibung |
---|---|
„core agorum"~2 | Erlaubt etwa, dass die Reihenfolge beider Wörter geändert werden kann oder zwei Wörter, etwa core und agorum, voneinander getrennt werden können, wie agorum core oder core der die agorum. |
Jedes String-Metadatum wird auf 3 Arten im Index abgelegt.
Art | Beschreibung |
---|---|
acmf_aktenzeichen | Standard |
acmf_aktenzeichen_ci (Caseinsensitiv) | In diesem String muss immer nach dem gesamten String gesucht werden. |
acmf_aktenzeichen_cs (Casesensitiv) | In diesem String muss immer nach dem gesamten String gesucht werden. |
Es kann aber auch nach jedem String exakt gesucht werden, indem " " um diesen gesetzt wird.
Hinweis: Bei einzelnen Metadaten im String-Format betrachtet das System den Inhalt als einen String. Es existiert das Metadatum und die Erweiterung _cs. In dieser Erweiterung betrachtet das System den Inhalt als einen einzelnen String. Bei Metadaten mit dem Datentyp STRING können Sie ebenfalls nur nach dem gesamten String suchen.
Suche nach | Treffer |
---|---|
acmf_stichworte:ag | ja |
acmf_stichworte:abc | ja |
acmf_stichworte_cs:ag | nein |
acmf_stichworte_cs:abc | nein |
acmf_stichworte_cs:abc* | ja |
acmf_stichworte_cs:(abc ag) | nein |
acmf_stichworte_cs:"abc ag“ | ja |
Tipp: Verwenden Sie die spezielle Suche nach * wie folgt:
acmf_stichworte:*
Findet alle Daten, die das Metadatum acmf_stichworte belegt haben. Alternativ können Sie auch allfields:acmf_stichworte verwenden, damit das System schneller sucht.
Diese Suche können Sie auch auf mehrere Metadaten anwenden: allfields:(acmf_stichworte OR acmf_anotherField)
Möchten Sie nach einem Wert in einem list-Metadatum suchen, müssen Sie das Präfix, Name des internen list-metadatums und interner Name des Positions-/Spaltenmetadatums mit einem Unterstrich verbinden.
Beispiel basierend auf einer metadata.yml-Datei:
# -- global _group: academy.workflow _prefix: academy_workflow_ _dataPrefix: MAIN_MODULE_MANAGEMENT/customers/academy.workflow/Data/ _csvPrefix: /agorum/roi/customers/academy.workflow/csv/ _encoding: UTF-8 ... positionen: displayName: Rechnungspositionen list: number: displayName: Nummer type: long
Das zusammengesetzte Metadatum für die Nutzung in einer Query lautet:
academy_workflow_positionen_number
Im Folgenden wird die Bereichssuche allgemein erklärt (egal welcher Datentyp, außer date).
In diesem Beispiel ist jahr eine Ganzzahl:
Suche | Beispiel |
---|---|
< less than | jahr:{* TO 2013} |
> greater than | jahr:{2013 TO *} |
<= less than or equal to | jahr:[* TO 2013] |
>= greater than or equal to | jahr:[2013 TO *] |
NOT jahr = nicht dieses Jahr | allfields:jahr NOT jahr:2013 |
Hinweis: Bei Solr hat sich der Syntax für die Datumssuche geändert. Die Erweiterungen datdate und datetime existieren nicht mehr. Für datetime existiert kein Ersatz.
Bei dieser Suche müssen Sie an das Metadatum noch die Ergänzung _date_range anhängen (alle Zeitangaben sind Zulu Time (d. h. GMT+0)):
Suche / Beispiel | Ergebnis |
---|---|
lastmodifydate_date_range:2014-01-01T00:00:00Z | alles von diesem Zeitpunkt |
lastmodifydate_date_range:2014-01-01 | alles von diesem Tag |
lastmodifydate_date_range:[2014-01-01 TO 2014-06-01] | alles zwischen 1.1.2014 und 1.6.2014 |
lastmodifydate_date_range:[2014 TO 2015] | alles zwischen 2014 und 2015 |
lastmodifydate_date_range:[2014-01 TO 2014-06] | alles zwischen Januar 2014 und Juni 2014 |
lastmodifydate_date_range:[2014-01-01T10 TO 2014-01-01T11] | alles zwischen 1.1.2014 10 Uhr - 1.1.2014 11 Uhr |
lastmodifydate_date_range:[NOW/DAY TO NOW/DAY+1DAY] | alles von heute |
createdate_date_range:[NOW-7DAY/DAY TO NOW] createdate_date_range:[NOW-7DAYS/DAY TO NOW] |
Alles, was am heutigen Tag erstellt wurde oder 7 Tage zurückliegt. Die Schreibweise 7DAY oder 7DAYS ist möglich. Die Angabe 7DAY/DAY erlaubt die Aufrundung der Uhrzeit auf Mitternacht. Lassen Sie diese Angabe weg und führen die Suche etwa um 15:30 Uhr aus, geht Solr 7 Tage zurück auf 15:30 Uhr und schließt somit nicht den ganzen Tag mit ein. |
Hinweis: Es gibt keine Möglichkeit, nur ein spezielles Jahr zu erhalten, etwa bei Benutzung der Range {2013 TO 2015}, in der Sie nur das Jahr 2014 erhalten möchten. Solr fügt intern ein Datum mit Monat, Tag und Uhrzeit an. Aus YYYY wird YYYY-0101T00:00:00Z. Das bedeutet, dass die Suche {2013 TO 2015} zu {2013-0101T00:00:00Z TO 2015-0101T00:00:00Z} intern umgeschrieben und für die Suche verwendet wird.
Keyword | Beschreibung |
---|---|
YEAR | Jahr |
MONTH | Monat |
DAY | Tag |
DATE (Synonym für DAY) | Datum / Tag |
HOUR | Stunde |
MINUTE | Minuten |
SECOND | Sekunden |
MILLISECOND | Millisekunden |
MILLI (Synonym für MILLISECOND) | Millisekunden |
Bei createdate müssen Sie noch die Ergänzung _date_range anhängen (alle Zeitangaben sind Zulu Time (d. h. GMT+0)):
Keyword | Beschreibung |
---|---|
createdate_date_range:[NOW-1YEARS TO NOW] | Wenn heute der 08.10.2016, 10:26:56 ist, wird wie folgt gesucht: von: 08.10.2015, 10:26:56 bis 08.10.2016, 10:26:56 |
createdate_date_range:[NOW-2YEARS TO NOW-1YEARS] | Wenn heute der 08.10.2016, 10:26:56 ist, wird wie folgt gesucht: von: 08.10.2014, 10:26:56 bis 08.10.2015, 10:26:56 |
createdate_date_range:[NOW-2YEARS/YEARS TO NOW-1YEARS/YEARS] | Wenn heute der 08.10.2016, 10:26:56 ist, wird wie folgt gesucht (und auf das Jahr gerundet: /YEARS): von 01.01.2014, 00:00:00 bis 01.01.2015 00:00:00 |
createdate_date_range:[NOW-2YEARS/DAY TO NOW-1YEARS/DAY] | Wenn heute der 08.10.2016, 10:26:56 ist, wird wie folgt gesucht (auf den Tag gerundet: /DAY): von 08.10.2014 , 10:00:00 bis 08.10.2015 ,10:00:00 |
createdate_date_range:[NOW-2YEARS/HOUR TO NOW-1YEARS/HOUR] | Wenn heute der 08.10.2016, 10:26:56 ist, wird wie folgt gesucht (und auf die Stunde gerundet: /HOUR): von: 08.10.2014, 11:00:00 bis 08.10.2015 ,11:00:00 |
createdate_date_range:[2014-01-01T00:00:00Z TO 2014-12-31T23:59:59Z] | Solr: [wert1 TO wert2]: die zwei Werte wert1 und wert2 sind inklusive. Lucene: {wert1 TO wert2}: die beiden Werte wert1 und wert2 sind nicht inklusive. Beide Varianten funktionieren mit Daten, Zahlen und Strings. Ein Datum muss als String mit folgendem Format angegeben werden: yyyy-MM-ddThh:mm:ssZ, also etwa 2014-10-20T15:10:49Z |
expirationdate_date_range:{1970 TO *] | Durch diese Syntax können Sie alle Objekte finden, die über ein gültiges Ablaufdatum verfügen. |
Für das allgemeine Arbeiten mit Date siehe https://lucene.apache.org/solr/guide/6_6/working-with-dates.html.
Für die Solr-Suche existieren spezielle Keywords und Keyword-Erweiterungen, die das System beim Indizieren eines Objekts belegt.
Tipps:
Keyword | Beschreibung | Beispiel(e) |
---|---|---|
allfields | Enthält alle Keywords, die auf diesem Objekt indiziert sind. Zu diesen Keywords gehören:
|
Alle Objekte finden, die etwa das Metadatum identifier besitzen, unabhängig davon, welchen Wert das Metadatum hat: allfields_ci:identifierAlle Objekte finden, die das Metadatum identifier nicht besitzen: * NOT allfields_ci:identifier |
allmetadatafields | Enthält alle Namen der Metadaten, die auf diesem Objekt indiziert sind. | Alle Objekte finden, die das Metadatum acmf_kundennummer besitzen, unabhängig vom Inhalt des Metadatums: allmetadatafields:acmf_kundennummer |
inpath | Enthält alle Ordner-IDs, unter denen das Objekt zu finden ist, bis zum Root-Ordner. Der Root-Ordner hat die feste ID 9999. |
Alle Objekte finden, die in einem Ordner verknüpft sind: inpath:9999 |
inpath_uuid | Enthält alle Ordner-UUIDs, unter denen das Objekt zu finden ist, bis zum Root-Ordner.
|
Alle Objekte finden, die im Ordner folder verknüpft sind (Suche per Skript): 'inpath_uuid:' + folder.UUID |
infolder | Enthält alle IDs, in denen das Objekt direkt verknüpft ist. | Alle Objekte mit IDs finden, die direkt unter Dateien stehen: infolder:${FOLDERPATH:/agorum/roi/files} |
infolder_uuid | Enthält die UUIDs, in denen das Objekt direkt verknüpft ist. | Alle Objekte mit UUIDs finden, die direkt unter Dateien stehen: infolder_uuid:${FOLDERPATH:/agorum/roi/files} |
contentonly | Enthält nur den Text eines Dokuments, ohne Metadatum. | Nur Dokumente oder E-Mails finden, in deren Inhalt der Text agorum willkommen steht. contentonly:(agorum willkommen) |
lastaddedbyuser | Enthält die Information, welcher Benutzer das Objekt zuletzt mit einem Ordner verknüpft hat.
|
Herausfinden, welche Objekte der Super-Administrator roi in der letzten Stunde in einen Ordner eingehängt hat: lastaddedbyuser:${USERID:roi} lastaddeddate_date_range:[NOW/MINUTE-60MINUTE TO *] |
lastaddeddate | Enthält die Information, wann ein Objekt zuletzt in einen Ordner verknüpft wurde. | siehe Keyword lastaddedbyuser |
deletedinfolder deletedinfolder_uuid deletedbyuser deletedbyuser_uuid deletedate |
deletedinfolder, deletedinfolder_uuid Enthält die ID und die UUID des Ordners, aus dem das Objekt gelöscht wurde. deletedbyuser, deletedbyuser_uuid Enthält die ID und die UUID des Benutzers, der das Objekt gelöscht hat. deletedate Enthält das Löschdatum des Objekts, d. h., wann es in den Papierkorb kam. |
– |
storagebackend | Enthält den Verweis auf den Speicherort des Objekts. none Inhalt in der Datenbank <uuid> Inhalt im Storage-Back-End mit dieser UUID |
Herausfinden, welche Objekte in der Datenbank abgelegt sind: storagebackend:noneHerausfinden, welche Objekte nicht in der Datenbank abgelegt sind: * NOT storagebackend:none |
ishistoryobject | Enthält die Information, ob es sich bei dem Objekt um eine Historie handelt oder nicht: ishistoryobject:true Bei dem Objekt handelt es sich um eine Historie. ishistoryobject:false Bei dem Objekt handelt es sich um keine Historie. |
– |
nameextension | Enthält den Teil des Namens hinter dem letzten '.', sofern vorhanden. | Nach allen PDF-Dateien suchen: nameextension:pdf |
basename | Enthält den Namen des Objekts ohne den Teil ab dem letzten '.', sofern vorhanden. | Nach Objekten suchen, in deren Namen das Wort test enthalten ist (etwa test abc.pdf): basename:test Nach Objekten suchen, in deren Namen ausschließlich das Wort test steht (etwa ein Ordner mit dem Namen test): basename_ci:(test) |
Solr verwendet für Queries auf Boolean-Felder intern folgende Methode:
@Override public String toInternal(String val) { char ch = (val!=null && val.length()>0) ? val.charAt(0) : 0; return (ch=='1' || ch=='t' || ch=='T') ? "T" : „F“; }
Die Suche beachtet somit nur das erste Zeichen:
Suche nach ... | Eingetragene Werte |
---|---|
boolean = True | T, t, 1 |
boolean = False | F, f, 0 |
In folgenden String-Metadaten kann auch mit einer regEx gesucht werden:
Bei einem regulären Ausdruck reicht kein Teilausdruck aus.
Beispiel
Sie suchen nach Ordnern, die das Namensformat „<Zahl von 0-9> . <Ordnernamen>“ aufweisen, etwa:
Hier reicht die Suche nach Folgendem nicht aus, um ein Ergebnis zu erzielen:
name_cs:/[0-9]\./
Stattdessen benötigen Sie etwa diesen Eintrag:
name_cs:/[0-9]\..*/
Syntax | Beschreibung |
---|---|
[0-9] | ein Zeichen in diesem Range : 0 OR 1 OR 2 OR 3 OR 4 OR 5 OR 6 OR 7 OR 8 OR 9 |
[a-z] | ein Zeichen aus dem Zeichenbereich, einschließlich der Endpunkte |
[abc] | ein Zeichen aus diesen Zeichen: a OR b OR c |
[^abc] | negierte Zeichen, also nicht a, b oder c |
/(xrtzu|baal)/ | xrtzu oder baal |
<1-1000> | eine Zahl zwischen 1 - 1000 jeweils einschließlich |
. | beliebiges Zeichen |
? | 0 oder ein Zeichen |
* | 0 - beliebig viele Zeichen |
+ | 1 - beliebig viele Zeichen |
{n} | n-Zeichen |
{n,} | n oder mehr Zeichen |
{n,m} | n- bis m-Zeichen (einschließlich beider Werte) |
\ | Escapted ein Sonderzeichen. |
In Strings kann nur eingeschränkt nach regEx gesucht werden, weil nur noch die Texte enthalten sind. Sonderzeichen wie .,[ # ] u.s.w sind darin nicht mehr enthalten und können nicht mehr gefunden werden.
Beispiel
Im Betreff einer E-Mail steht Folgendes:
agorum - Hallo bitte lesen [#atgp9887]
Jetzt sollen alle E-Mails gesucht werden, die [#atgpXXXXX] beinhalten, wobei XXXX eine beliebige Ganzzahl sein kann. Im String ist jetzt im Index nur noch das enthalten:
agorum - Hallo bitte lesen atgp9887
Hier es fehlen also die Steuerzeichen [# und ]
Jetzt kann also nur gesucht werden nach E-Mails, die atgpXXXXX im Subject haben. Bei Strings kann wie folgt per regEx gesucht werden:
Beispiel 1
subject:/atgp[0-9]+[0-9]/
Bei diesem Beispiel wird ein Wort gesucht, das mit atgp beginnt, dann können beliebige Zahlen folgen und am Ende muss eine Zahl stehen.
Beispiel 2
subject:/atgp<0-10000>/
Bei diesem Beispiel wird ein Wort gesucht, das mit atgp beginnt, dann muss eine Zahl kommen zwischen 0 - 10000 (einschließlich).
Beispiel 3
subject:/atgp[0-9]{1,4}/
Bei diesem Beispiel wird das Wort gesucht, das mit atgp beginnt, dann muss eine Zahl zwischen 1 - 4 Ziffern kommen.
Beispiel 4
/(xrtzu|baal)/
Bei diesem Beispiel wird das Wort xrtzu oder das Wort baal gesucht.
Der Unterschied ist hier, dass in diesen Feldern alle Zeichen stehen. Diese bedeutet, man kann in diesen Feldern auch nach den Sonderzeichen suchen. Beispiel für solche Felder sind folgende:
Hier wäre eine Suche wie folgt möglich:
Im Name steht folgender String:
agorum - Hallo bitte lesen [#atgp9887]
Jetzt kann danach gesucht werden:
name_ci:/.*\[\#atgp[0-9]{1,8}a\].*/
Achtung: Beeinträchtigung der Systemleistung durch Verwenden von RegEx innerhalb von ci und cs-Feldern. Suchen Sie nur außerhalb dieser Felder mit regExs, um das System nicht unnötig zu belasten.
Folgende Zeichen haben in Solr eine besondere Bedeutung.
+ - && | | ! ( ) { } [ ] ^ " ~ * ? : \
Möchten Sie nach einem solchen Zeichen suchen, verwenden Sie ein vorangestelltes \.
Um etwa nach (1+1):2 zu suchen, verwenden Sie folgende Abfrage:
\(1\+1\)\:2
Hinweis: Sonderzeichen sind nur in den ci- und cs-Feldern vorhanden.
age:[18 TO 30] // findet age 18-30 inclusive (die Endpunkte 18 und 30 sind mit dabei) age:[18 TO 30} // findet age>=18 und age<30 age:[65 TO *] // „open ended“ range findet age>=65 age:[* TO *] // findet alle Dokumente in denen age gesetzt ist
description:HDTV /* TODO: +promotion:tv +promotion_date:[NOW/DAY-7DAYS TO NOW/DAY+1DAY] */
Mit Solr können Sie verknüpfte Suchen (Join-Suchen) durchführen.
Hinweis: Diese Art der Suche kann bei größeren Datenmengen länger dauern. Diese Funktion sollte daher nur in Sonderfällen zum Einsatz kommen, bei denen die Dauer der Suche keine Rolle spielt. Alternativ sollten Metadaten vergeben werden, die ein direktes Suchen von Objekten ermöglicht.
Beispiel
Sie suchen nach Rechnungen eines Lieferanten, dessen Name Lieferant 1 lautet. Dieser Lieferantenname sollte als Metadatum auf dem Objekt sitzen, damit danach gesucht werden kann.
Die allgemeine Syntax lautet:
{!join from=X to=Y}Q
X und Y sind jeweils Feldnamen und Q eine gültige Solr-Query.
In einer SQL-Abfrage würde das Ganze zur Verdeutlichung folgendermaßen lauten:
select * from t where t.Y = (select X from t where Q)
Damit das Ganze mit der agorum core-Suche funktioniert, muss diese Query speziell eingepackt werden (gelb markiert):
_query_:"{!join from=X to=Y}Q"
In dem folgenden Beispiel sollen alle Objekte gefunden werden, bei denen der Ersteller (creator) ein Benutzer ist, dessen fullName: demo ist:
_query_:"{!join from=uuid to=creator_uuid_ci}fullname:demo"
Intern sucht das System nun nach allen Objekten, bei denen fullname:demo lautet, und liefert die uuid zurück (from). Dann werden alle Objekte gesucht, deren creator_uuid_ci den UUIDs entspricht, die bei der vorgehenden Suche zurückkamen.
Hinweis: Es können nur kompatible Felder verwendet werden, also alle String-Felder und dort deren Lower-Case Variante, d. h. immer Feldname _ci. IDs funktionieren nicht miteinander. Ein Vergleich mit ID und creator (für das obige Beispiel) funktioniert nicht, da ID ein spezieller Datentyp ist, der inkompatibel ist. Deshalb wird hier auf uuid zurückgegriffen.
Die Suche kann auch beliebig eingeschränkt werden. Etwa sollen alle Dokumente, die eine PDF-Datei sind und deren Ersteller demo ist, gesucht werden:
nameextension:pdf _query_:"{!join from=uuid to=creator_uuid_ci}fullname:demo"
In folgendem Beispiel sollen alle Objekte gefunden werden, die in Ordner A und in Ordner B (oder darunter) vorkommen, die aber direkt in einen Ordner unterhalb von B verknüpft sind, aber nicht in einem Ordner von A. Es soll also herausgefunden werden, ob Objekte direkt in Ordner B verknüpft sind oder indirekt über einen Ordner, der auch in A vorkommt.
(inpath:${ID:/agorum/roi/Files/B} inpath:${ID:/agorum/roi/Files/A}) _query_:"{!join from=uuid to=infolder_uuid_ci}isfolder:true inpath:${ID:/agorum/roi/Files/B} NOT inpath:${ID:/agorum/roi/Files/A}"
Diese Suche kann relativ lange dauern (bei größeren Datenmengen). Eine Alternative wäre, die Suche auf 2 Suchen aufzuteilen:
Suche 1
isfolder:true inpath:${ID:/agorum/roi/Files/B} NOT inpath:${ID:/agorum/roi/Files/A}
Hier wird nun eine Reihe von Objekten zurückgegeben, davon benötigen Sie alle UUIDs. Die Anzahl der UUIDs darf 1024 nicht überschreiten, da sonst die Suche 2 nicht funktioniert, weil ein Limit erreicht wird.
Suche 2
(inpath:${ID:/agorum/roi/Files/B} inpath:${ID:/agorum/roi/Files/A}) infolder_uuid_ci:(UUID1 OR UUID2 OR ....)
Mit Function Queries ist es möglich, komplexe Suchanfragen mit Bedingungen durchzuführen:
Hinweis: Diese Art der Suche kann bei größeren Datenmengen länger dauern. Diese Funktion sollte daher nur in Sonderfällen zum Einsatz kommen, bei denen die Dauer der Suche keine Rolle spielt.
Der Aufbau ist wie folgt, am Beispiel Suche von docx Dateien, bei denen das createDate und lastModifyDate unterschiedlich sind:
nameextension:docx _query_:"{!frange l=0 u=0} if(eq(createdate,lastmodifydate), 1, 0)"
Möchten Sie etwa alle Objekte haben, bei denen beide Datumsangaben gleich sind, können Sie entweder l=1 und u=1 wählen oder 0,1 beim IF schreiben.
nameextension:pdf _query_:"{!frange l=1 u=1} if(gt(createdate, lastmodifydate), 1, 0)"
_query_:"{!frange l=1 u=1} if(eq(mainobject_uuid_ci,uuid), 1, 0)"
_query_:"{!frange l=100000 u=2174960 incu=false} product(image_height, image_width)"
Suche alle Bilder, bei denen das image_height * image_width >= 100.000 und < 2.174.960 liegt. incu=false bedeutet, dass das Upper-Limit ausgeschlossen ist. Für den Lower-Wert wäre es incl (Standard ist true).
Sie können komplexe Suchanfragen formulieren. Somit ist es auch möglich, Wildcards in Phrasen, also zusammenhängende Suchbegriffe, zu verwenden.
Hinweis: Diese Art der Suche kann bei größeren Datenmengen teilweise Minuten dauern. Diese Funktion sollte daher nur in Sonderfällen zum Einsatz kommen, bei denen die Dauer der Suche keine Rolle spielt.
_query_:"{!complexphrase inOrder=true}name:\"ago* Software GmbH\"“
Parameter | Beschreibung |
---|---|
!complexphrase | Leitet die komplexe Suche ein. |
inOrder | true bedeutet, dass die einzelnen gesuchten Worte genau in der Reihenfolge vorkommen müssen |
identifier:kundenakte _query_:"{!complexphrase inOrder=true}name:\"ago* Software GmbH\"“
Suche | Lucene | Solr |
---|---|---|
Alles was geändert wurde vor 1 Tagen bis heute | lastmodifydatedatedate:[${ACTDATE:-1} TO 99990101000000] | lastmodifydate:[NOW-1DAY TO *] |
Alles was geändert wurde vor 30 Tagen bis heute | lastmodifydatedatedate:[${ACTDATE:-30} TO ${ACTDATE:0}] | lastmodifydate:[NOW-30DAY TO *] |
Vor einem Tag (in Sekunden) bis Heute | lastmodifydatedatedate:[${ACTDATETIME:-86400} TO 99990101000000] | lastmodifydate:[NOW-86400SECONDS TO 99990101000000] |
Suche nach / in Positionsmetadaten:
Diese zeigt an, was der aktuell angemeldete Benutzer als letztes bearbeitet hat. Ausgeschlossen werden Versionen vom Wiki. Angezeigt werden alle Treffer bis 30 Tage zurück:
Lucene | Solr |
---|---|
(((lastmodifier:${USERID:} -wikiversion:true AND (ancestors:globalobject AND (lastmodifydatedatedate:[${ACTDATE:-30} TO ${ACTDATE:0}]))))) | (((lastmodifier:${USERID:} -wikiversion:true AND (ancestors:globalobject AND (lastmodifydatedatedate:[NOW-30DAY TO *]))))) |
Hinweis: Die weitere Suchsyntax für Lucene und Solr finden Sie im Internet.