j3nsch
commented
2 years ago Dieses Ticket ist noch relevant.
Bei einer Änderung eines Collectionnamens unter "institute", müssen erst alle Dokumente neu indexiert werden, die dieser Collection zugeordnet sind, damit diese Dokumente auch in der Facette unter dem geänderten Namen angezeigt werden. Wenn nicht alle Dokumente indexiert werden, werden zwei Collectionnamen in der Facette angezeigt - der aktuelle Name und der alte Name. Die Durchführung der asynchronen Jobverarbeitung (Indexierung der Dokumente über den cronjob) hat nichts gebracht, da nur geänderte Dokumente indexiert werden.
Aktuell wird per Default die Collection Role institues auch als Facette verwendet, d.h. die Namen der zugehörigen Collections treten als Facettenwerte auf.
Folgende Änderungen an institutes-Collections (über die Sammlungsadministration) müssen daher immer auch immer in den Index (genauer: zu den assoziierten Dokumenten im Index) propagiert werden:
Collection wird unsichtbar/sichtbar (darf dann sie nicht mehr als Eintrag in der Institute-Facette auftreten bzw. muss wieder sichtbar gemacht werden) Collection wird umbenannt (Umbennung muss dann in der Institute-Facette erscheinen) Collection wird gelöscht (Eintrag darf dann nicht mehr in der Institute-Facette erscheinen) Hinweis: Es gibt im Zuge von Matheon auch noch die Collection Role projects, die eine Sonderbehandlung erfährt und auch als Facette angezeigt wird. Somit gelten die o.g. Beobachtungen auch hier.
Außerdem werden die Zuordnungen zwischen Dokumenten und Collections (ist eine n:m-Relation) im Index gehalten, nämlich im searchable multi-valued field collection_ids, um die Dokumente im Browsing anzeigen zu können ohne die Datenbank befragen zu müssen.
Somit muss der Inhalt des Felds collection_ids aktualisiert werden, wenn eine Collection bzw. Collection Role (dann die ID der Root Collection) gelöscht wird – dann muss die Collection ID in allen assoziierten Dokumenten im Index gelöscht werden.
Bemerkung: Dass die collection_ids bei Collection-Updates nicht korrekt nachgezogen werden, ist nicht ganz so schlimm, da es aktuell nur einen Use-Case für diese gibt. Im Browsing wird eine Suche mit der ID der ausgewählten Collection gestartet. Damit geht die Aktion aber immer von der Collection selbst aus. Ist die Collection unsichtbar oder wurde sie gelöscht, dann wird sie im Browsing nicht angezeigt und es kann gar nicht zu einer Anfrage mit einer Collection-ID kommen, die im Index "verschmutzt" ist.
Ideen zur Lösung
Kurzum: Wir müssen sicherstellen, dass die Dokumente auch Änderungen an den Collections mitbekommen. Das ist die Ursache der Fehler. Das bedeutet aber, dass jede Änderung in den Collections zu einem Indexupdate (und zwar für die assoziierten Dokumente) führt. Da Solr keine Einzelfeld-Updates erlaubt, müssten wir für die betroffenen Dokumente
Das ist ziemlich aufwendig und kann insbesondere bei Collections, die sehr viele assoziierte Dokumente haben, einen Timeout provozieren, wenn die Indexierung zu lange dauert.
Lösungsidee: Wir nutzen die Schemafreiheit von Solr bewußt aus. Es gibt fortan im Index zwei Indexdokumente pro Opus-Dokument. Für alle textuellen Suchen wird das aktuell vorhandene Dokument verwendet (das enthält auch den durchsuchbaren Volltext). In diesen Dokumenten wird fortan das Indexfeld collection_ids entfernt.
Für Collection-Suchen (dort, wo die Eingabe eine Collection-ID ist – d.h. im Browsing) wird auf eine Light-Version des Dokuments zurückgegriffen. Dieses enthält das Feld collection_ids und sämtliche Felder, die für die Suchtrefferanzeige (stored="true") bzw. die Facettierung benötigt werden. Nur diese Light-Dokumente müssen nun bei Änderungen an den Collections gepflegt werden. Da z.B. der Volltext hier nicht zu den Feldern gehört, ist die Neuindexierung dieser Dokumente relativ unaufwendig.
Diese Idee löst das Problem nur teilweise, da das Indexfeld institues auch für die "gewöhnliche" textuelle Suche benötigt wird, um dort die Facettenwerte für die Institutes-Facette zu generieren.
eine bessere Idee:
Wir verändern die Indexinhalte von institutes und collection_ids bei den o.g. Collection-Operationen nicht, sondern bauen bei der Anzeige der Werte in der Institutes-Facette einen Filter ein und verwenden den Feldinhalt nicht mehr direkt, sondern speichern im Feld nun die Collection-ID statt des Namens der Collection ab. Bei der Ausgabe eines Wertes führen wir dann folgende Schritte aus:
Wichtig bei der Umsetzung dieser zweiten Idee ist, dass keine Opus_Collection-Objekte instanziiert werden, sondern das Framework Funktionen bereitstellt, die direkt auf die Datenbank gehen und nur atomare Werte zurückgeben (für die o.g. Abfragen reicht wohl ein Boolean).
noch ein wichtiger Punkt, der sichergestellt werden muss: Wenn die Eigenschaften von CollectionRole bzw. Collection (z.B. Visible in Browsing / OAI) geändert werden, dann muss auch diese Änderung propagiert werden.
Intern: https://tickets.zib.de/jira/browse/OPUSVIER-1362