DQL versteht gültige Suchabfrage nicht mehr, wenn FT-Index vorhanden ist

[pantelis.botsas]

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:

Code

numFieldName >= 5

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.

Code

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

[pantelis.botsas]

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

Code

numFieldName >= 5

abzufragen, schränke ich das gewünschte Ergebnis mit

Code

not numFieldName = ''

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

Code

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

Code

dateBegin >= @dt('2022-01-01')

muss man bei gleichzeitig vohandenem Volltextindex umschreiben in

Code

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

[eknori]

Ich hatte heute Zeit, mich ein wenig intensiver damit zu beschäftigen. Ich kann Deine Beobachtungen verifizieren. Da ist ganz gehörig der Wurm drin.

Ich bereite mal einen Case für den HCL support vor.

[eknori]

Ich teste gerade das feature "named foundsets" in DQL (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.

Code

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

Code

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. 

[pantelis.botsas]

Guten Morgen

Vielen Dank für Deine Unterstützung, Ulrich.

In dem von mir beobachteten Fall sind in der Datenbank knapp 2000 Dokumente vorhanden. Somit sollte das Problem hier nicht die Ergebnismenge sein.

Was jedoch meiner Beobachtung nach einen Einfluss hat, sind Dokumente, welche auf unterschiedliche Masken aufbauen und das Zahlenfeld nicht in allen Masken vorhanden ist. Ich werde versuchen, diesen Verdacht durch einen Testaufbau zu überprüfen, um den Fehlerfall weiter einzugrenzen.

Schönen Sonntag 

PS: Dadurch das wir hier wieder ein Produktset haben, dem wir durch drumherum Programmieren müssen, das beizubringen versuchen, was es eigentlich mit Standardfunktionen geben soll, ist die Weiterentwicklung der Anwendung komplett eingestellt worden (Kosten- / Zeitziel verfehlt). Nun wird eine Lösung in der Konkurrenzwelt gesucht  , welche diese Anwendung ablösen wird.

[eknori]

Ich habe den Case bei HCL aufgemacht. Hier die erste Antwort

Firstly, thanks for providing the database and steps to reproduce the problem in-house. I've tested in Domino 12.0.1, and I was able to recreate the issue. Looking into further, I found a similar report SPR # JCUSBLBR7Q whereas the DQL causes GTR memory overflow with the same exact error message we have here. However, this report has been addressed in version 11.0.1. So, I will be verifying if this is an exact match, or if it's a regression and conduct few testing accordingly.

[eknori]

Ich nehme an, Du hast den FT Index schon einmal gelöscht, und wieder neu erstellen lassen. Oder ein update Index durchgeführt.

Bei kleineren Datenmangen (600k Dokumente) funktioniert meine Abfrage problemlos.
HCL DEV wundert auch, dass Du die 32MB limit Meldung schon bei 2k Dokumente bekommst.

Du solltest in jedem Fall auch einen case aufmachen.

[pantelis.botsas]

Ich nehme an, Du hast den FT Index schon einmal gelöscht, und wieder neu erstellen lassen. Oder ein update Index durchgeführt.

Ja, das habe ich bereits durchgeführt, was jedoch das Problem nicht gelöst hat.

Bei kleineren Datenmangen (600k Dokumente) funktioniert meine Abfrage problemlos.
HCL DEV wundert auch, dass Du die 32MB limit Meldung schon bei 2k Dokumente bekommst.

Ich führe meine Abfrage über das AppDev-Pack (in einem NodeJS Backend) auf eine Mailbox durch, in der von außen Dokumente mit einem Zahlenfeld angelegt werden. Die Abfrage liefert mir das richtige Ergebnis, solange der FT-Index in der Mailbox nicht angelegt ist. Sobald dieser erstellt wird, kommt die oben genannte Fehlermeldung.

Ich habe jetzt alle für diese Abfrage nicht relevanten Dokumente in der Mailbox gelöscht. Es sind nur noch 53 Dokumente vorhanden. Der Fehler wird immer noch ausgegeben.
Somit habe ich meine eigene Vermutung vom 20.03.2022 widerlegt. Es ist irrelevant, ob die Dokumente auf einer Maske oder mehreren Masken basieren.

Jetzt habe ich eine Teststellung, die ich auch genau so weiter geben kann.

[pantelis.botsas]

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:

Code

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.

[eknori]

Da kommt der gleiche Mist raus

Code

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

[eknori]

Latest update from HCL support

Hello Ulrich,

Good day.

This is to update you on this case. Please know that I have created SPR # MAVACCTJKC to document this errant behavior. At this point, I'm now working closely with the product development to conduct a source-code level investigation to potentially identify the cause, and remediation accordingly.

I'll keep you posted, and share feedback no later than Tuesday (03/29/2022).

Thanks and have a great day ahead.

Best Regards,

[eknori]

Support hat einen KB Artikel gepostet. https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0097581
Der Artikel enthält MEINEN Code 

Und die Lösung ist so einfach wie genial ...

Case ist jetzt ins Development eskaliert

[pantelis.botsas]

Vielen Dank für die Zusammenfassung.

Somit gibt es an dieser Stelle erst einmal folgende Situation:

Wäre die Nutzung des Volltext-Indizes vorgegeben (weil die Benutzer auch in der Datenbank suchen können sollen), dann ist der Einsatz des AppDev-Pack für diese Anwendung nicht möglich.

Es sei denn, man erzeugt für jede diese Anwendungen jeweils eine Replik OHNE FT-Index.
Das wird ein Spaß, wenn die über das AppDev-Pack angebundenen Anwendungen die Mail-Files aller Mitarbeiter sind. 

Oder man programmiert - wie so oft - um den Bug herum und verliert den eigentlich erwünschten Performance-Gewinn. 

[pantelis.botsas]

Meine Ergänzungen wurden als weiterer Hinweis im von Ulrich genannten Artikel (https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0097581) aufgenommen:

Important Note: The issue also manifests in DQL query engine via the AppDev-Pack.

[eknori]

Die Fixlist für die (gegen Ende des Jahres) geplante Domino V12.0.2 enthält folgenden Eintrag:

SPR# MAVACCTJKC - Programmabilty - DQL - Fixed an issue where DominoQuery was not working for a very large application when it had a FT Inde

https://ds_infolib.hcltechsw.com/ldd/fixlist.nsf/8ed1b46cfdba8957852570c90054623b/e34d3e93c4aa50668525884b0056fb0d?OpenDocument

[pantelis.botsas]

Dann hoffen wir mal, dass sie das AppDev Pack nicht vergessen  .

Doch für mich hat die Kombination mit Domino und AppDev Pack nicht einmal das Stadium einer Frickelei erreicht  .
Kein Projekt mehr mit diesem vollkommen undurchsichtig agierenden und sinnlos kompliziert zu konfigurierenden Bastelsatz  .

Hoffentlich schaffen die bei Project Keep die Kurve.