-
Notifications
You must be signed in to change notification settings - Fork 7
Dokumente mit ungültigen ORCID iDs beim Speichern markieren
#369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Einige der Probleme könnten umgangen werden, wenn die Markierungen außerhalb der eigentlichen Metadaten der Dokumente gespeichert würden. Es gibt bereits ein einfaches Properties System für das Speichern von zusätzlichen Informationen über Objekte, wie Dokumente, Personen und Dateien. Das Properties System ist aber unter anderem noch nicht in die Indexierung integriert, so dass basierend auf diese Informationen keine Facette erstellt werden kann. Die notwendigen Änderungen sind zu groß für einen Patch Release und würden unter anderem ein neues Solr-Schema erfordern. Abgesehen davon gibt es für OPUS 4.8.* zwei opus4-search Packages, für PHP 7 und 8, die beide geändert werden müssten. Letztendlich sind für die Suche einige Bereinigungen notwendig, die vor der Umsetzung neuer Funktionen erfolgen sollten. Der einzige gangbare Weg im Augenblick sind also Enrichments. |
Aufgrund der aktuellen Hindernisse bei der Umsetzung einer "synchronen" Prüfung von ORCID iDs beim Speichern, sollte für OPUS 4.8.0.13 erst einmal eine "asynchrone" Prüfung umgesetzt werden, die von außen, unabhängig von der internen Implementation im Framework, erfolgen kann. In OPUS4/application#1307 geht es um ein Kommando für die Validierung aller ORCID iDs in der Datenbank. Dabei könnten Dokumente mit Problemen markiert werden. |
Ein kurzfristige Lösung wäre vielleicht eine neue |
Das Markieren der Dokumente ohne eine Aktualisierung von ServerDateModified kann erreicht werden in dem man den LifecycleListener vom Dokument entfernt bevor es gespeichert wird. Dabei muss natürlich darauf geachtet werden, dass keine anderen relevanten Änderungen vorgenommen werden. Diese Methode scheint aber auch die Indexierung des Dokumentes nach dem Speichern zu verhindern. |
Beim Speichern soll eine Validierung stattfinden, wenn eine ORCID iD ungültig ist, soll das Dokument so markiert werden, dass das Problem in einer Facette angezeigt werden kann.
Es gibt die Funktionen
isValid
undgetValidationErrors
in der Implementation des Datenmodells. Diese werden zur Zeit nicht mehr oder kaum verwendet, weil irgendwann beschlossen wurde, Validierungen in den Formularen durchzuführen, aber im Framework auch das Speichern von ungültigen Werten zuzulassen. Ob das die richtige Entscheidung war, ist nicht ganz klar, aber hier nicht das Thema.Beim Speichern von ORCID iD Werten werden jetzt vorangestellte URL-Teile entfernt. Dabei könnte auch eine Validierung stattfinden, um bei importierten Dokumente, die nicht in Formularen validiert wurden, ungültige Werte zu erkennen und die Dokumente entsprechend zu markieren.
Ein Problem ist, dass an dieser Stelle im Code, in der
storeIdentifierOrcid
-Funktion, nicht andere Element, Enrichments, des Dokuments manipuliert werden können oder sollten. Es kann auch zu Race-Conditions kommen, wenn z.B. die Validierung für das gesamte Dokument vorgenommen wird und die Speicherfunktion hinterher den Wert verändert, in dem sie den URL-Präfix entfernt. Wird die Prüfung später angesetzt, sind die Enrichments vielleicht schon gespeichert worden, bevor das Dokument markiert werden kann.Es muss überlegt werden was ein sinnvolles, robustes Design wäre und dann muss man schauen was mit der aktuellen Implementation ohne viel Aufwand möglich ist. Es kann sein, dass die notwendigen Kompromisse im Augenblick zu groß sind.
The text was updated successfully, but these errors were encountered: