You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
undAllowEmailContact
. 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.
The text was updated successfully, but these errors were encountered: