Skip to content
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

Person-Feld(er) von Document mit Doctrine umsetzen #204

Open
j3nsch opened this issue Nov 16, 2021 · 0 comments
Open

Person-Feld(er) von Document mit Doctrine umsetzen #204

j3nsch opened this issue Nov 16, 2021 · 0 comments

Comments

@j3nsch
Copy link
Member

j3nsch commented Nov 16, 2021

Personen sind ein kompliziertes Thema. Für den Umbau von Opus\Person gibt es zwei Issues #156 und #155. In Issue #155 geht es darum die vielen Verwaltungsfunktionen aus der Modellklasse heraus zu lösen. Wie die Personenverwaltung in Zukunft aussehen wird ist noch unklar. Für Document geht es erst einmal nur darum die existierende Funktionalität mit Doctrine umzusetzen.

Es gibt ein Person-Feld, das alle verknüpften Personen umfasst. Darüber hinaus gibt es Person[Role]-Felder, die sich nur auf die verknüpften Personen in einer bestimmten Rolle, wie "Author" oder "Referee", befinden. Die Verknüpfung selbst hat auch drei Properies, Role, SortOrder und AllowEmailContact. Mit SortOrder kann die Reihenfolge von Autoren festgelegt werden, mit AllowEmailContact kann ein Autor für jedes Dokument entscheiden, ob er kontaktiert werden kann.

Die Personen-Objekte werden bisher nicht gelöscht, wenn ein Dokument gelöscht wird. Sie sind eigenständige Entitäten. Allerdings ist OPUS 4 bisher so umgesetzt worden, dass für jedes Dokument neue Person-Objekte angelegt werde. Das heißt, wenn ein Dokument gelöscht wird, verwaisen Personen-Einträge in der Datenbank. Das müssen wir jetzt im ersten Schritt nicht fixen. Hier müssen die genauen Pläne in separaten Issues noch ausgearbeitet werden. Vermutlich werden wir aber in Zukunft die verknüpften Personen mit dem Dokument löschen.

Momentan sind alle Person-Felder vollwertige Field-Objekte. Das heißt z.B., dass das Person-Feld erst alle Personen enthält, die über Funktionen mit konkreten Rollen wie setPersonAuthor hinzugefügt wurden, wenn das Document wieder aus der Datenbank geladen wurde. Die Informationen aus der Tabelle werden dabei auf die Felder verteilt. Ich denke es ist sinnvoll, wie bereits bei Identifiern, nur ein Property Person zu mappen und die Setter und Getter für konkrete Rollen in der Modellklasse zu handhaben.

Da es unwahrscheinlich ist, dass sich die Liste der Rollen ändert könnte man aber auch alternativ für jede Rolle ein separates Property definieren. Alle Person-Properties würde auf die gleiche Tabelle gemappt. In diesem Fall wäre ich dafür das Person-Property für alle Personen zu entfernen, um keine redundanten Informationen mehr im Speicher zu halten. Die Funktionen für "Person" könnten aber im Modell umgesetzt werden, um Kompatibel zu bleiben und eine einfaches Iterieren über alle Personen zu ermöglichen.

Egal welchen Ansatz wir wählen, von außen sollte es keinen Unterschied machen. Bei den Änderungen muss zumindest später berücksichtigt werden, dass das OPUS-XML momentan direkt über die Field-Objekte generiert wird und daher dort die Personen-Informationen doppelt auftauchen, einmal als Person-Element und dann noch mal als Element mit der Rolle, also z.B. PersonAuthor. Die Redundanz sollte beseitigt werden. Vermutlich macht es mehr Sinn im XML nur noch Person-Elemente zu haben. Die existierenden XSLT-Skript müssen dann umgestellt werden, aber dafür gibt es dann separate Issues.

Für diese Ticket geht es erst einmal nur um das Mapping in Document und das Verknüpfungsobjekt.

@j3nsch j3nsch added this to the Framework 4.8 Beta milestone Nov 16, 2021
haogatyp added a commit that referenced this issue Mar 24, 2022
haogatyp added a commit that referenced this issue Mar 24, 2022
@j3nsch j3nsch removed this from the Framework 4.9 Beta milestone Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant