search

OPUS4 / application

OPUS 4 application.
Other
15 stars 21 forks source link

Bereinigung von Volltext-Cache bei Datei-Änderungen #718

Open j3nsch opened 2 years ago

j3nsch commented 2 years ago

Wenn eine Datei gelöscht wird, wird die Extraktionsdatei im Volltextcache bisher nicht enfernt. Das soll behoben werden.

Intern: https://tickets.zib.de/jira/browse/OPUSVIER-4388

j3nsch commented 2 years ago

Die Verbindung zwischen Datei und Volltextextrakt wird über den Hash hergestellt. Das Extrakt wird in einer Datei mit dem Hash im Namen gespeichert. Der Hash wird immer wieder neu berechnet. Dadurch wird verhindert, dass eine Datei ausgetauscht wird und ein altes Extrakt verwendet wird. Das klappt auch, wenn die Datei im Hintergrund an OPUS 4 vorbei ausgetauscht werden. Allerdings sorgt es auch für immer wieder neue Hashberechnungen, die bei großen Dateien sehr aufwendig sein können. Jede Operation dauert dadurch länger.

Es muss überlegt werden, was hier schwerer wiegt, der Schutz gegen Inkonsistenzen nach der Manipulation von Dateien oder Performanz. Macht es mehr Sinn den Hash einmal zu berechnen und in der Datenbank abzulegen, statt ihn immer wieder zu berechnen? Es muss dann eine Funktion geben, die prüft, ob der Hash in der Datenbank für die gespeicherte Datei gültig ist. Diese Funktionen würde nur für Prüfungen verwendet werden, aber nicht ständig im normalen Betrieb.

Gibt es Hinweise aus dem Betrieb? Wenn nein, dann bitte einfach nur einen kurzen Kommentar schreiben. Ich würde sagen Performanz ist wichtiger, da die Manipulation der Dateien außerhalb von OPUS 4, die Ausnahme bilden sollte.

Das geht natürlich über den Scope dieses Tickets hinaus, aber auch hier wird es einfacher, wenn ich den für die Bereinigung des Caches nicht noch einmal den Hash der Datei berechnen muss, die gelöscht werden soll.

j3nsch commented 2 years ago

Ich würde der Performanz auch mehr Gewicht geben. Der Fall, dass die Datei ausgetauscht wird, ist sehr selten.

j3nsch commented 2 years ago

Wir haben Plugins, die z.B. dafür sorgen, dass Dokumente neu indiziert oder auch aus dem Index entfernt werden. Die Plugins reagieren auf das Speichern bzw. Löschen von Dokumenten. In diesen Plugins ist es aber nur schwer erkennbar, ob eine Datei gelöscht wurde. Das Plugin, müsste die Dateien im Document-Object mit den Dateien in der Datenbank abgleichen. Das würde zu noch mehr schwer verständlichen und nicht wartbaren Code führen.

Es macht Sinn das Konzept eines "Datei gelöscht Events" einzuführen und dann entsprechend darauf zu reagieren. Allgemeiner könnte man vielleicht über "FieldChangeEvents" nachdenken. Beim Löschen einer Datei hat sich das Feld "File" eines Dokuments geändert. Diese Events sollten dann den alten und den neuen Wert bekommen, um darauf reagieren zu können. Es müsste überlegt werden, ob ein solches Plugin bereits vor dem Löschen, dem Speichern der Änderung aufgerufen werden soll.

Das ist kompliziert und muss durchdacht werden. Es nicht sauber zu lösen kostet uns über die Jahre hinweg mehr, hat es schon.

j3nsch commented 2 years ago

Ich schaue es mir doch noch mal für die 4.8 an. Evlt. kann man ein Plugin für Opus\File schreiben, das beim Löschen einer Datei aufgerufen wird. Die File-Plugins sind immer noch fest verdrahtet. Das neue Plugin gehört aber in den Search-Code. Hier muss also die Konfigurierbarkeit der Plugins für Opus\File hinzugefügt werden.