Bug #1043

Textsuche in Logs fehlerhaft

Von mic@ vor mehr als 1 Jahr hinzugefügt. Vor 12 Monaten aktualisiert.

Status:erledigt% erledigt:

100%

Priorität:2 mittel
Zugewiesen an:following
Zielversion:Version 3.1.5
Ticket Referenz: Kategorien:suche logs

Beschreibung

Ich hatte dieses Log vom User "Hemicellulose" gesehen im Listing:

  1. Diesen Cache hatte ich bisher nur auf GC geloggt (s.u.).
  2. Der Vollständigkeit halber möchte ich den Logeintrag aber nachholen ...

Quelle http://www.opencaching.de/viewcache.php?wp=OCCDCF / "Waldspielplatz Klövensteen"

In diesem Log kommt ja das Wort >Vollständigkeit< vor.
Aber wenn ich nun nach Text in Logs suche, wird mir dieser Treffer bzw. dieses Listing nicht angezeigt?!?!

Zugehörige Revisionen

Revision 0f4c5479
Von following vor 12 Monaten hinzugefügt

rewritten fulltext index updating; updates #1043

Revision abc4377a
Von teiling88 vor 12 Monaten hinzugefügt

Merge pull request #622 from following5/1043-logsearch

rewritten fulltext index updating; updates #1043

Historie

#1 Von teiling88 vor mehr als 1 Jahr aktualisiert

  • Zugewiesen an wurde auf nlubisch gesetzt
  • Zielversion wurde auf Version 3.1.3 gesetzt

#2 Von nlubisch vor mehr als 1 Jahr aktualisiert

  • Status wurde von neu zu in Arbeit geändert

#3 Von nlubisch vor mehr als 1 Jahr aktualisiert

  • Status wurde von in Arbeit zu erledigt geändert
  • % erledigt wurde von 0 zu 100 geändert

Meinen Tests zufolge, funktioniert die Suche nur bei nicht archivierten Caches.
Veröffentlichte Caches tauchen mit identischer Beschreibung bei der Suche nach dem Wort im Cache Log "Vollständigkeit" auf.

#4 Von mic@ vor mehr als 1 Jahr aktualisiert

Man kann ja bei der Suche...
https://www.opencaching.de/search.php

...oben angeben, ob auch das zu suchende in archivierten Caches gesucht werden soll.
Wenn man also den Haken entfernt, also archivierte Caches NICHT ausblendet, und
dann nach "Vollständigkeit" in Logs sucht, dann sollte eigentlich dieses Log hier
gefunden werden...

https://www.opencaching.de/viewcache.php?cacheid=155786&log=A#log1074693

...tut es aber leider nicht!

#5 Von teiling88 vor mehr als 1 Jahr aktualisiert

  • Status wurde von erledigt zu offen geändert
  • Zielversion wurde von Version 3.1.3 zu Version 3.1.4 geändert
  • % erledigt wurde von 100 zu 0 geändert

#6 Von nlubisch vor mehr als 1 Jahr aktualisiert

@Michael: Ich hab gerade nochmal intensiv bei mir lokal probiert dein Problem nachzustellen. Ob “Cache ausblenden > Archivierte“ Angehakt oder nicht und Cache veröffentlicht oder archiviert - ich kann bislang keinen Fehler feststellen obwohl ich es auf der Liveseite ebenfalls nachvollziehen kann. Kannst du deine Suche nochmal ausfüllen und abschicken und mir hier die komplette URL zukommen lassen?

Vielleicht finde ich noch etwas was ich anders mache wie du.

#7 Von nlubisch vor mehr als 1 Jahr aktualisiert

  • Status wurde von offen zu in Arbeit geändert

#8 Von following vor etwa 1 Jahr aktualisiert

  • Kategorien wurde auf suche logs gesetzt

Ich konnte das Problem eben sowohl auf www.opencaching.de als auch auf test.opencaching.de und meinem Entwicklersystem reproduzieren. Der Testserver und mein Entwicklersystem (identische Daten) lieferten insgesamt 25 Treffer, www.opencaching.de mit denselben Sucheinstellungen nur 17 Treffer!

Dann habe ich auf meine Entwicklersystem den Suchindexeintrag für das betreffende Log (ID 1074693) neu erzeugt, und nun waren es plötzlich 26 Treffer - einschließlich des Caches "Waldspielplatz Klövensteen".

Hab weitere Wörter getestet, mit und ohne deutsche Umlaute, aber die waren alle ok.

Für die weitere Diagnose bräuchte ich einen Dump der Tabellen search_index und search_index_times vom Produktivserver, und das Ergebnis dieser Abfrage:

SELECT id,last_modified FROM cache_logs

@teiling88: Kannst du mir die drei Tabellendumps zusenden oder irgendwo bereitstellen? Sind alles unsensible Daten, die man problemlos veröffentlichen kann.

#9 Von following vor etwa 1 Jahr aktualisiert

Bei #1020 ist das Problem auch nochmal aufgefallen.

Wäre nett wenn ich die drei DB-Dumps bekomme, um nach der Ursache forschen zu können.

#10 Von following vor etwa 1 Jahr aktualisiert

  • Zugewiesen an wurde von nlubisch zu teiling88 geändert

Ich weise dir das mal zu wegen Datenbankabfrage OC-Produktivserver, danach bitte an mich. :)

#11 Von teiling88 vor etwa 1 Jahr aktualisiert

  • Zielversion wurde von Version 3.1.4 zu Version 3.1.5 geändert

#12 Von teiling88 vor etwa 1 Jahr aktualisiert

  • Zugewiesen an wurde von teiling88 zu following geändert

#13 Von following vor etwa 1 Jahr aktualisiert

  • Zugewiesen an wurde von following zu teiling88 geändert

Das war nun die unwichtigste von den drei angeforderten Tabellen. ;)

Die Daten bitte wenn möglich als Dump, nicht als formatierte Ausgabe einer Query - dann lässt sich das direkt wieder an MySQL/MariaDB verfüttern. Geht im phpMyAdmin mit "Exportieren", oder mit mysqldump.

#14 Von teiling88 vor etwa 1 Jahr aktualisiert

  • Zugewiesen an wurde von teiling88 zu following geändert

-> und das Ergebnis dieser Abfrage:

hast Du erhalten.

-> Die Daten bitte wenn möglich als Dump

hast Du auch erhalten. Im Archiv ist noch ein Archiv...

#15 Von following vor etwa 1 Jahr aktualisiert

Alles klar, nun hab ich's gefunden.

#16 Von following vor etwa 1 Jahr aktualisiert

  • Priorität wurde von 1 niedrig zu 2 mittel geändert

#17 Von following vor etwa 1 Jahr aktualisiert

Hash "Vollständigkeit" = 2006368161 (OCCDCF, cacheid 155786, logid 1074693)

Hash "KnallKopfKommando" = 1268944419 (OCBBFE, cacheid 151223, logid 1151343)

Auf dem Testsystem insgesamt 42 Logwort-Hashes für Cache 155786, auf dem Produktivsystem 17 - obwohl es bei letzterem zwei Logs mehr sind.

#18 Von following vor etwa 1 Jahr aktualisiert

Der Fehler liegt hier. Die Funktion war so gedacht, dass sie die Indexeinträge für ein einzelnes Objekt - z.B. ein einzelnes Log - löscht, bevor dieses neu indiziert wird. Tatsächlich löscht sie aber den gesamten Index für alle Logs dieses Caches. Geht auch gar nicht anders, da dieser Index - zur Vermeidung von Redundanz - nur als Gesamtmenge für alle Logs des Caches vorhanden ist.

Im Ergebnis funktioniert die Volltextsuche in Beschreibungen, Bildtiteln und Logs jeweils nur bei dem neuesten Objekt: Der zuletzt bearbeiteten Beschreibung, dem zuletzt hochgeladenen oder geänderten Bild und dem zuletzt eingestellten oder editierten Log. Alle anderen fehlen im Suchindex. Das war offenbar schon immer so - die Volltextsuche für alles andere als den Cachetitel hat noch nie richtig funktioniert.

Um das Problem zu beheben, muss die Logik zum Indizieren von Beschreibungen, Bildern und Logs überarbeitet werden.

Der derzeitige Suchindex belegt ca. 400 MB Speicherplatz und verteilt sich wie folgt:

  • 6 Mio. Wörter in Cachebeschreibungen
  • 1,6 Mio. Wörter in Logs
  • 0,2 Mio. Wörter in Cachenamen
  • 0,06 Mio. Wörter in Bildtiteln

Durch den Bugfix erhöht sich die Zahl der Cachebeschreibungseinträge um ca. 5%, die der Bildtitel-Einträge um ca. 50% und die der Logeinträge um ca. 1270%. In der Summe sind das rund 1 GB zusätzliches Datenvolumen zu den bisher vorhandenen schätzungsweise 1,5-2 GB. Das wird spürbar sein, aber verkraftbar. :-)

Der Indexneuaufbau würde einige Stunden dauern, kann aber problemlos im laufenden Betrieb erfolgen.

#19 Von following vor etwa 1 Jahr aktualisiert

Ein weiterer Bug an gleicher Stelle: Beim Löschen von Beschreibungen, Logeinträgen oder Bildern blieben die Texte im Suchindex. Also gelöschte Texte wurden weiter gefunden.

#20 Von following vor etwa 1 Jahr aktualisiert

  • Status wurde von in Arbeit zu im Test geändert
  • % erledigt wurde von 0 zu 90 geändert

#21 Von following vor 12 Monaten aktualisiert

  • Status wurde von im Test zu erledigt geändert
  • % erledigt wurde von 90 zu 100 geändert

Auch abrufbar als: Atom PDF