Umstellung Hibernate Search − weitere Fragen #6095
Replies: 7 comments 12 replies
-
Vielen Dank für diesen Überblick über den aktuellen Entwicklungsstand.
Wenn ich die Arbeitsschritte in Issue #5760 richtig verstehe, wird es in jedem Fall eine Suche nach den Metadaten der meta.xml im Index geben. Die Tatsache, dass die zwei Funktionalitäten nicht zur Verfügung stehen, ist also auch dadurch bedingt, dass die Metadatensuche noch nicht implementiert ist, richtig? Grundsätzlich halte ich es für recht hilfreich die Werte in der Datenbank zu speichern; wir haben im Fall der PPN bei der Erarbeitung der Spezifikation für den Re-Import bereits darüber nachgedacht (#5904), dies aber erstmal verworfen, da Altdaten entsprechend migriert werden müssten. Daher stellt sich die Frage: Macht eine Umstellung dieser Werte vom Index auf die Datenbank nicht eine Migration der Altdaten nötig? Wären für letztere - bzw. für die Bereitstellung eines Migrations-Werkzeugs - weitere Entwicklungsarbeit nötig? |
Beta Was this translation helpful? Give feedback.
-
Nur um dies als Option in den Raum zu stellen: Falls sich Kitodo (und insbesondere eine datenbankgestützte Lösung) dadurch deutlich beschleunigen ließe, wäre evtl. zu diskutieren, ob der hohe Aufwand für die Ermittlung des Icon-Status überhaupt betrieben werden muss. Beispiel: Das Icon "Papierkorb" könnte auch immer aktiv geschaltet werden. Die Überprüfung, ob der Vorgang gelöscht werden kann, würde erst erfolgen, wenn ein Nutzer auf das Icon klickt. |
Beta Was this translation helpful? Give feedback.
-
Ich habe das Thema mit @matthias-ronge besprochen.
Weiteres Vorgehen: @solth: Falls es Gründe gibt, die gegen dieses Vorgehen spricht, darfst/sollst Du natürlich hier gerne Dein "Veto" anmelden. |
Beta Was this translation helpful? Give feedback.
-
Vielleicht bin ich jetzt etwas pragmatisch unterwegs, aber ich würde gerne im CB die verschiedenen use cases mal kurz sammeln, um zu gucken, welche Bedarfe es überhaupt gibt. Danach können wir ja gucken was sich technisch wie umsetzen lässt. Wenn man schon alles neu baut und guckt wäre das eine gute Gelegenheit mal zu gucken was man tatsächlich braucht. Ich kann z. B. aus Halle berichten, dass ich wahrscheinlich durch die Erziehung mit Kitodo 2 im wesentlichen nach dem Prozessnamen suche und erst anfange die Vorteile des Indexes zu erkennen, aber da definitiv nicht alle Metadaten drin brauche. Ich vermute mal in den anderen größeren Häusern gibt es ähnliche Standardfälle und bevor wir gucken was technisch wie optimal umgesetzt werden kann, können wir ja mal gucken was tatsächlich mit welcher Prio nötig ist, bevor es Verschiebungen zw. Index und Datenbank gibt. |
Beta Was this translation helpful? Give feedback.
-
@matthias-ronge danke für das Update zum aktuellen Bearbeitungsstand des Projekts. Gut zu hören/lesen, dass es prinzipiell zu funktionieren scheint. Ein paar Anmerkungen von mir zu den von Dir erwähnten Punkten: zu 1.: ich wäre dafür, die Informationen, die benötigt werden, um bestimmte Icons zu deaktivieren, in der Datenbank abzuspeichern, wenn wir nur so die aktuelle Funktionalität behalten können, selbst, wenn es nicht so schön ist. Funktionalität muss meiner Meinung nach über "Schönheit" der Implementierung stehen. zu 2.: ich wäre dafür, nicht fest immer "PPN" als Spalte zur Vorgangs-Tabelle hinzuzufügen, sondern stattdessen explizit solche funktionalen Metadaten, die im Regelsatz mit zu 3.: gab es hier nicht eine Möglichkeit, solche Informationen einer Entität mit Hilfe der zu 4.: auf die Funktionalität gänzlich zu verzichten ist aus meiner Sicht keine Option, besonders, da Du ja schon zwei potentielle Lösungsvorschläge aufgezählt hast. Vielleicht können wir hier ähnlich verfahren wie mit dem zu 5.: ich glaube, dass es sehr wichtig ist, dass die Funktionalität des Filter-Schlitzes erhalten bleibt, daher bin ich dankbar, dass Du das explizit erwähnst. Das sollten wir nicht aus den Augen verlieren. |
Beta Was this translation helpful? Give feedback.
-
Wir (@solth , @matthias-ronge , @stefanCCS ) hatten noch ein weiteres Abstimmungsmeeting mit folgendem Ergebnis zu den oben genannten Punkten:
==> Dass heißt: Es gibt aus Anwendersicht keine Änderung zur bisherigen Version: Somit die Frage an @apiller , @BartChris: Brauchen wir noch das Meeting mit dem CB? |
Beta Was this translation helpful? Give feedback.
-
Ohne den neuesten Stand des Branch explizit getestet zu haben (https://github.com/matthias-ronge/kitodo-production/tree/5760_1c_3), einmal die Nachfrage nach dem funktionalen Stand und der konkreten Zielstellung der Implementierung. Dies insbesondere auch im Hinblick darauf, dass es in den Anwenderbibliotheken spezifische Hauptnutzungsszenarien für die Suche gibt, die auf dem aktuellen Stand getestet werden sollten. Wenn ich den Code richtig verstehe, wurde eine große Zahl von Anfragen (Tasks, Projekte) vom Index auf Datenbank-Queries verlagert. Die Re-Implementierung der erweiterten Suchmöglichkeiten ohne expliziten Zugriff auf Elasticsearch (die eigentliche Hibernate-Search-Implementierung) steht noch aus(?). Im Rahmen von Gesprächen im @kitodo/kitodo-community-board wurden die folgenden Aspekte als wesentlich identifiziert, bei denen es wichtig wäre, unabhängig von der technischen Implementierung Stand und Perspektiven der Entwicklung einordnen zu können:
|
Beta Was this translation helpful? Give feedback.
-
Ich freue mich, Ihnen mitteilen zu können, dass die ElasticSearch-durch-Hibernate-Search-ersetzen-Entwicklung inzwischen so weit fortgeschritten ist, dass ich einen Branch zur Verfügung stellen kann, der kompiliert und startet und größtenteils funktioniert, ohne den ElasticSearch-Index aktiv zu verwenden. Der selbst geschriebene ElasticSearch-Code wurde noch nicht entfernt, das wird der nächste Schritt sein.
Die Zwischenversion hat jedoch einige Punkte aufgezeigt, die in Zukunft möglicherweise etwas anders behandelt werden müssen und der Diskussion bedürfen.
Um die Anwendung zum Laufen zu bringen, musste ich das Lazy Loading für Projekte und Vorgänge deaktivieren. Für Projekte werden Vorgänge und Vorlagen derzeit sofort mitgeladen. Für Vorgänge werden die Kommentare und untergeordneten Vorgänge derzeit mitgeladen. Dies ist für größere Datenbanken unmöglich. Ich denke, der einzige Grund, warum sie sofort geladen werden müssen, ist, um zu prüfen, ob einige Symbole (wie der Papierkorb) dargestellt werden sollen. Ich weiß noch nicht, ob dies überhaupt mit der Hibernate-Search-Integration gelöst werden kann, da es sich um ein Suchframework handelt. Wahrscheinlich wird die erforderliche Lösung darin bestehen, zusätzliche Datenbankspalten mit den redundanten aber erforderlichen Informationen hinzuzufügen. Dies hat den Vorteil, dass die Anwendung ohne laufenden Index verfügbar ist. Das Speichern redundanter Informationen in einer Datenbank ist jedoch immer unschön.
Suchen eines vorhandenen übergeordneten Vorgangs anhand seiner PPN während des Katalogimports. Die PPN war nur im Index für die Suche verfügbar. Sollte das so bleiben oder sollte die PPN im Prozessdatensatz in der Datenbank gespeichert werden? Da die PPN wichtig ist und auch beim erneuten Importieren der Metadaten eine Rolle spielen wird, könnte man argumentieren, sie in der Datenbank zu speichern. Man könnte sie dann auch in der Vorgangsliste anzeigen.
Das Sortieren der Vorgangsliste nach den auf die letzte bearbeitete Aufgabe bezogenen Spalten „Letzter Bearbeitungsbenutzer“, „Beginn der Bearbeitung der letzten Aufgabe“, „Beendigung der Bearbeitung der letzten Aufgabe“ und „Status des Korrekturkommentars“ ist derzeit nicht möglich. Dies erfordert wahrscheinlich ein explizites Feld zur Markierung der „letzten Aufgabe“ im Vorgang, um die ersten drei Probleme zu beheben. Das vierte Problem hängt mit Punkt 1, Status Korrekturkommentar im Vorgang, zusammen.
Beim manuellen Hinzufügen eines untergeordneten Vorgangs zu einem übergeordneten Vorgang im Metadateneditor vergleicht der Suchschlitz nicht mehr mit den zulässigen Doctypes. Die Möglichkeiten sind, auf die Funktionalität zu verzichten, den Dokumenttyp im Vorgang in der Datenbank zu speichern, oder die Funktionalität nur mit laufendem Index verfügbar zu haben.
Der Filter-Schlitz ist derzeit nicht implementiert, er erkennt nur IDs zur sofortigen Navigation oder unterstützt die Suche nach einem Titel-Teil. Dies ist in der Zwischenversion beabsichtigt und wird später auf dem Hibenate-Search-Framework umgesetzt.
Ich habe diese Diskussion eröffnet, um die Punkte 1-4 zu diskutieren.
Beta Was this translation helpful? Give feedback.
All reactions