Hallo zusammen,
ich kämpfe mich mit diesem AppDev-Pack ab und habe mich heute gewundert, warum eine bisher tadellos funktionierende DQL-Suche nicht mehr funktioniert.
Die DQL-Abfrage enthält nichts Kompliziertes:
Sie funktioniert auch bei fast allen Anwendungen. Und ich habe sehr viel Zeit damit verbracht, nach einem Fehler in der Abfrage zu suchen, weil die Fehlermeldung in der Konsole einerseits sagt, dass ich keine Berechtigungen zur Durchführung der Aktion besitze, um mir dann wenige Zeilen später den DQL Query als fehlerhaft anzumahnen.
error: [2021-12-16 23:50:02] You are not authorized to perform that operation - error during planning and tree generation
numFieldName >= 5
(Call hint: FTCalls::FTSearchExt, Core call #0)
******************
Nun stellt sich heraus, dass die Abfrage in den wenigen Anwendungen deshalb nicht funktioniert, weil in den Anwendungen gleichzeitig der Volltextindex vorhanden ist.
Lösche ich den Volltextindex in den Anwendungen, beruhigt sich die Konsole wieder und die Abfrage funktioniert in allen Anwendungen.
Sobald der Volltextindex wieder gesetzt ist, kann ich nur noch nach Zeichenketten suchen. Numerische Werte bzw. Datum führen zur oben genannten Fehlermeldung.
Kennt jemand dieses vollkommen abenteuerliche Verhalten und weiß, wie man DQL und Volltextindex gleichzeitig auf einer Anwendung brauchbar nutzen kann?
Liebe Grüße aus Stuttgart,
Pantelis
Hallo zusammen
Ich habe nun eine ganze Weile gebraucht, um die Anforderung so umzusetzen, damit die DQL-Abfrage auch mit einem vorhandenen Volltextindex funktioniert.
Doch dabei leidet die Ausführungsdauer ein wenig.
Zur "Umleitungslösung":
Statt das numerische Feld in DQL mit
abzufragen, schränke ich das gewünschte Ergebnis mit
ein.
Ich erhalte jedoch dadurch ein Ergebnis mit allen Dokumenten, in denen dieses Feld vorkommt.
Interessanterweise liefert diese Suchabfrage aber auch Dokumente zurück, in denen das Feld eigentlich nicht vorkommen sollte, aber mit dem Feldwert undefined :-:
Im Anschluß daran führe ich per Javascript eine Filterung der Ergebnisse durch
result = result.filter((e) => e.numFieldName && e.numFieldName > 5)
Was mir am Ende dann die Dokumente zurückliefert, die ich auch tatsächlich für die weitere Verarbeitung benötige.
Und noch eine Kleinigkeit:
Diese funktionierende Suchabfrage mit DQL ohne Volltextindex
dateBegin >= @dt('2022-01-01')
muss man bei gleichzeitig vohandenem Volltextindex umschreiben in
dateBegin >= @dt('2022-01-01T00:00:00.000Z')
damit die Abfrage weiterhin funktioniert ::).
Ich hoffe, ich konnte damit dem einen oder der anderen eine kleine Hilfe geben.
Pantelis
Ich teste gerade das feature "named foundsets" in DQL (https://help.hcltechsw.com/dom_designer/beta/12.0.1/basic/wn_dqlnamedresults.html (https://help.hcltechsw.com/dom_designer/beta/12.0.1/basic/wn_dqlnamedresults.html))
Meine application hat ca. 4.5 Mio Dokumente.
Über einen Java Agenten greife ich von einer anderen Anwendung auf die Applikation zu
Der Agent führt folgendes Query aus, und die Anzahl der zu findenden Dokumente is knapp 50.000. Also nicht sonderlich viel.
query = "idNumber > 20 AND idNumber < 30";
Das query funktioniert auch prima, solange die Datenbank keinen FT Index verwendet.
Sobald der Index erstellt ist, und ich das Query ausführe, laufe ich in den bereits erwähnten Fehler. Der Index ist ca 1.9 GB gross.
Ich habe danach eine neue Datenbank angelegt und Daten über ein kleines Script erzeugt. Zunächst ca 20.000 Dokumente. Die Datenbank ist FT enabled, und der Index wurde nach Erstellen der Dokumente aktualisiert.Der FT Index ist erwartungsgemäß klein, bei der kleinen Menge an Dokumenten.
Hier funktioniert auch das query anstandslos.
Danach habe ich über mein Script immer mehr Dokumente in der Datenbank erstellt, und den Index jedes Mal aktualisiert. Keine Fehler bei der Ausführung des query.
Die Datenbank enthält momentan knapp 700.000 Dokumente; die Anzahl gefundener Dokumente liegt bei 10.000.
Ich habe dann das query geändert, um herauszufinden, ob es ggfs. ein Problem mit dem Rückgabewert geben könnte.
Zwar habe ich
dominoQuery.setMaxScanDocs(Integer.MAX_VALUE);
dominoQuery.setMaxScanEntries(Integer.MAX_VALUE);
gesetzt, um die DEFAULT Werte zu überschreiben, und es sollte aus dieser Richtung keine Probleme geben.
Das query gibt problemlos jede beliebige Menge an Treffern zurück. 100k, 200k, 300k. Alles kein Problem.
Von HCL DEV habe ich folgende Information bekommen.
GTR has a hard limit of 32MB of results. We can increase that maybe but more likely will be a consolidation of terms by DQL into a single GTR query. We've already done a bit of that, and yeah, a support ticket would help assure it's done.
The idea of the feature, though is even if you do NOT have a FT index, you can run the query using NSF scanning , taking 20 minutes even, and save its results for 1 msec retrieval subsequently. You do not NEED special views or FT indexes if you have a foundset that is static for a time (even a day, say).
Das eigentliche Problem scheint also das "hard limit of 32MB of results" zu sein. Wobei ich denke, dass man "GTR results" nicht mit der Menge ( und kumulierter Größe ) der gefundenen Dokumente gleich setzen darf.
Ich habe versucht, über ein FT DEBUG mehr herauszufinden, aber das DEBUG liefert ausgerechnet im Fehlerfall gar keine Informationen.
Soweit dies erst einmal. Ich bleibe dran.
Hallo Ulrich
Hast Du mal versucht, direkt in der Serverkonsole über die DomQuery Utility die gleiche DQL-Abfrage zu stellen?
Folgendes Beispiel habe ich jetzt versucht in einer Mailbox, in der sich Dokumente befinden, welche das Feld flagByHolidayYear mit den Wert 2020-2026 enthalten:
Form = 'Appointment' and chair = 'CN=General User/O=MyTest' and principal = 'CN=General User/O=
MyTest' and endDate >= @dt('2022-01-01T00:00:00.000Z') and flagByHolidayYear >= 2022
Ich erhalte über die Konsole die Anzahl der Treffer.
Doch führe ich die Abfrage über das AppDev-Pack aus, kommt der besagte Fehler. In den entsprechenden Mail-Datenbanken liegen zwischen 60 und 60.000 Dokumente. Und das Ergebnis ist überall gleich.
Da kommt der gleiche Mist raus
load domquery -f faker.nsf -q "idNumber > 20 and idNumber < 30"
Full text error; see log for more information - error during planning and tree generation
idNumber > 20 and idNumber < 30
(Call hint: FTCalls::FTSearchExt, Core call #0)
******************
Full text error; see log for more information
[1BC4:0002-21DC] 23.03.2022 13:57:42 Full Text message: Work area overflown due to many hits. Error-Number = 387
[1BC4:0002-21DC] 23.03.2022 13:57:42 GTR search error for "h:\faker.ft\ftgi": Work area overflown due to many hits. Error-Number = 387: Full text error; see log for more information