HCL Notes / Domino / Diverses > Entwicklung

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

(1/4) > >>

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
--- Ende Code ---

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)


******************
--- Ende Code ---


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
--- Ende Code ---
abzufragen, schränke ich das gewünschte Ergebnis mit

--- Code: ---not numFieldName = ''
--- Ende Code ---
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)
--- Ende Code ---

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')
--- Ende Code ---
muss man bei gleichzeitig vohandenem Volltextindex umschreiben in

--- Code: ---dateBegin >= @dt('2022-01-01T00:00:00.000Z')
--- Ende Code ---
damit die Abfrage weiterhin funktioniert  ::).

Ich hoffe, ich konnte damit dem einen oder der anderen eine kleine Hilfe geben.

Pantelis

eknori (retired):
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 (retired):
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";
--- Ende Code ---

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);
--- Ende Code ---

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.


--- Zitat ---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).
--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[#] Nächste Seite