Suche findet weiterhin gelöschte Inhalte

brische

Hallöchen,

wir haben folgendes Problem:
Nachem wir in der Kategorie Buchhaltung eines Servers Daten z.B. in Inventarnummer gelöscht haben,
werden diese Werte weiterhin in der Suche gefunden und vorgeschlagen.
Folgt man dann dem Link der Suche wird es aber als Leeres Feld angezeigt.
Genauso wird er auch über den ./controller gefunden.
Trotz eines search_index reindex per Controller sowie auch durchstarten der mySQL-DB und des Apaches und löschen des Caches auf dem Server wird immer der alte Wert weiterhin gefunden.
Erst wenn der Wert mit was anderem als '0' oder '-' oder ' ' (Leerzeichen) überschrieben wird, wird nur noch der neue Wert gefunden.
Das Problem tritt aber auch in den anderen Felder wie z.B. Lieferschein-Nummer auf.
Der Fehler ist bei uns in der Version 1.8.1 PRO sowie auch nach dem Update 1.8.2 PRO reproduzierbar.

Mit sonnigen Grüßen
Bernd

dkirsten

Hallo,

haben das gerade nachgestellt, es ist ein Bug. Wir haben es aufgenommen und dann sollte das zur 1.8.3 gelöst sein.

brische

Hallöchen,

vielen Dank für die schnelle Rückmeldung.
Dann bin ich beruhigt, dass nicht wir zu dumm waren das System sauber zu betreiben
Daher warten wir also ab und gehen dann wieder Tee trinken

Mit sonnigen Grüßen
Bernd

jd

Hallo noch einmal,

unsere Entwickler haben sich das Thema noch einmal genau angesehen. Anscheinend ist dies die übliche Arbeitsweise der Indexierung in MySQL. Einen ständigen "Refresh" einzubauen würde die Performance merklich verringern. Die Empfehlung der Kollegen lautet daher, den Reindex der Suche zum Beispiel in einem Intervall von fünf Minuten, automatisch mit einem Aufruf des Controllers durch einen CronJob durchzuführen: https://kb.i-doit.com/display/de/Suche#Suche-Indexierung
Hierdurch sind gelöschte Daten maximal fünf Minuten nach dem Zeitpunkt, zu dem sie gelöscht wurden, auffindbar.

Lieben Gruß
jd

brische

Hallöchen jd,

wie ich bereits geschrieben habe:

Trotz eines search_index reindex per Controller sowie auch durchstarten der mySQL-DB und des Apaches und löschen des Caches auf dem Server wird immer der alte Wert weiterhin gefunden.

Das heißt das geleerte Feld wird nicht neu indexiert trotz des Befehles: $ ./controller -u admin -p admin -i 1 -m search_index reindex
(natürlich Benutzer/kennwort angepasst)
Was auch in eurer Anleitung als Erklärung zu finden ist:

Wortlänge

Eine wichtige Frage lautet, wie lang ein Wort mindestens sein muss, damit es indexiert wird. Häufig steht dieser Wert auf 3 Zeichen. Begriffe wie "PC 01" werden hiermit nicht gefunden. Geeignet wäre die Angabe von 2 oder sogar 1 Zeichen.
innodb_ft_min_token_size = 2 # minimale Zeichenanzahl eines Suchbegriffes

Diese Einstellung könnte dazu führen, dass der Index um ein vielfaches größer wird.
Worttrenner

Um Wörter voneinander zu unterscheiden, werden verschiedene Zeichen als Worttrenner herangezogen (z. B. Leerzeichen, Punkt, Strich). Damit der Begriff "PC-01" gefunden wird, wird dieser in "PC" und "01" aufgeteilt. Hier ist also wieder die Wortlänge entscheidend, ob "PC" und "01" indiziert werden oder nicht.

Das erklärrt auch warum das Sonderzeichen "-" nicht als neuer Wert erkannt wird….Bzw. der Index nicht erstellt wird, weil die Wortlänge dann wohl 0 oder 1 ist. Bisher habe ich mich nicht getraut die Wortlänge zu ändern bzw. zu reduzieren. Da die Reduzierung auf 0 glaube ich erst recht nicht vorteilhaft sein kann. Aber dazu habe ich zu wenig Erfahrung.

Mit sonnigen Grüßen
Bernd

brische

Hallöchen,

ich habe nun nochmal weiter gegraben…
Als Beispiel das oben genannte Feld Inventarnummer, welches sich in der Tabelle isys_catg_accounting_list und der Spalte isys_catg_accounting_list__inventory_no gespeichert wird, ist nicht als Index-Feld in der MySQL-DB definiert. Daher kann es kein MySQL-Indexierungsproblem sein.

Es sieht eher danach aus, dass eben I-DOIT selber den Index nicht sauber erstellt.
Denn nach dem das Feld gelöscht wird, ist der Wert weiterhin in der Tabelle isys_search_idx enthalten. Wie bereits geschrieben auch ein ReIndex über den Controller löscht es dort nicht.

Bevor ich aber einen TRUNCATE TABLE isys_search_idx; und den Index über den Controller neu aufbauen lasse, würde ich gerne die Meinung der Experten hören

kmauel

Guten Morgen Bernd,

bitte einmal anstatt einen reindex einen fullindex ausführen, davor jedoch bitte das TRUNCATE auf die isys_search_idx um einen sauberen Stand zu haben.

Dies sollte dann den Index korrekt anlegen.

Viele Grüße,

Kevin Mauel

brische

Hallöchen Kevin,

vielen Dank für den Hinweis zum Fullindex.
Also ich habe es nun bei uns getestet und kann berichten, dass dies meinen Fehler korrigiert.
Wir werden dies wohl jetzt per Cronjob einmal in der Nacht durch führen.
Bin aber der Meinung, dass das per Cronjob löschen der Tabelle und den Index neu aufbauen lassen, nur ein Workaround sein kann. Der bei ca. 3000 Objekten nur ca. 50 Sekunden dauert.
Aber da die Tabelle eh von I-doit geführt wird, sollten auch die Werte vom System selbst automatisch gelöscht werden.
Genauso könnte man einen weiteren Button Index Neu Aufbauen in der "Verwaltung / Systemtools / Cache - Datenbanken / Datenbank" einführen um solche Fehlerhaften Einträge löschen zu können…

Mit sonnigen Grüßen
Bernd

kmauel

Hallo Bernd,

Sehr gut das nun alles wie gewünscht funktioniert. Ein Cronjob für den Suchindex ist sowieso ratsam.
Gute Anregungen für mögliche Verbesserungen unserer Suche, werden wir gerne mit in Betracht ziehen!

Ein schönes Wochenende!