Opus\Document auf Doctrine umstellen

[j3nsch]

Document ist die umfangreichste Modellklasse, die wir bei OPUS 4 haben. Dokumente sind mit Referenz-Metadaten verknüpft, wie zum Beispiel DNB-Institute, und hier muss es in Zukunft weitere Veränderungen geben. Für den Augenblick versuchen wir als Zwischenschritt die Funktionalität so zu erhalten wie sie ist.

Dokumente haben einige Metadaten, wie Title, Identifier, Enrichment, die in anderen Tabellen gespeichert werden, aber immer nur zu einem einzigen Dokument gehören. Diese Metadaten sollen langfristig als Block gespeichert und nicht mehr über viele Tabellen verteilt werden. Das ist aber ein großer Schritt, bei dem viele Teil auf einmal geändert werden müssen. Daher wäre es vermutlich sinnvoll die Document-Klasse erst einmal für das aktuelle Datenbankschema auf Doctrine umzustellen. Das ORM sollte keine Probleme haben Title und andere Entitäten auf die existierenden Tabellen zu verteilen. Wenn sich dass innerhalb weniger Entwicklungstage umsetzen ließe, dann würde sich dieser Zwischenschritt lohnen, um früher mit dem Umbau der Application für Laminas beginnen zu können.

Durch diesen Zwischenschritt würde auch der weitere Umbau einfacher werden, weil dadurch bereits viel Code verschwinden wird, der im Augenblick noch für Verwirrung sorgen kann. Der nächste Schritt wird dadurch später einfacher.

Falls es bei der Umsetzung mit Doctrine-ORM und den aktuellen Tabellen Probleme gibt, muss dieser Plan überdacht werden. Was auch noch nicht abschätzbar ist, sind die Auswirkungen auf die Performanz von OPUS 4. Mit DBAL scheinen die Zugriffe auf die Datenbank schneller geworden zu sein. Ob das auf ORM auch zutrifft, muss sich erst noch zeigen.

[j3nsch]

Wir sollten hier eine neue Document-Klasse anlegen und erst einmal nur ein internes und ein externes Property anlegen, dann ein komplexes Property, wie TitleMain, das selber ein Objekt ist und eine Verknüpfung zu einer anderen Entität wie z.B. einer Lizenz. Einfach nur für jedes Art von Verknüpfung ein Beispiel. Wenn das funktioniert, können wir den ganzen Rest umsetzen.

[j3nsch]

Es ist noch unklar, ob alle Felder von Document mit ORM umgesetzt werden können.

TODO Wenn ein Teil der Informationen mit DBAL gespeichert werden müssen, während Document im Allgemeinen mit dem EntityManager gespeichert wird, können wir trotzdem die gesamte Operation in einer Transaktion durchführen? Hoffentlich lassen sich gemischt Operationen vermeiden, aber z.B. bei den Sammlungen, die mit NestedSet (#131 ) umgesetzt werden ist mir noch nicht klar, ob wir dafür das ORM verwenden können.

[j3nsch]

Ich denke hier in diesem Ticket sollten die einfachen Felder von Document gemappt werden. Für die verknüpften Modelle, die in eigenen Tickets gespeichert werden, gibt es separate Issues, die in einem Projekt gesammelt sind.

https://github.com/OPUS4/framework/projects/6

Die einfachen Felder umfassen:

$fields = [
    'BelongsToBibliography',
    'CompletedDate',
    'CompletedYear',
    'ContributingCorporation',
    'CreatingCorporation',
    'ThesisDateAccepted',
    'ThesisYearAccepted',
    'Edition',
    'EmbargoDate',
    'Issue',
    'Language',
    'PageFirst',
    'PageLast',
    'PageNumber',
    'ArticleNumber',
    'PublishedDate',
    'PublishedYear',
    'PublisherName',
    'PublisherPlace',
    'PublicationState',
    'ServerDateCreated',
    'ServerDateModified',
    'ServerDatePublished',
    'ServerDateDeleted',
    'ServerState',
    'Type',
    'Volume',
];

[j3nsch]

Ich denke wir sollten zuerst Document mit den einfachen Feldern hier umsetzen und dann dieses Ticket offen lassen, bis die anderen Issues für die Verknüpfungen abgearbeitet sind. Der Branch für dieses Ticket hier sollte document heißen. Für jede Verknüpfung, jedes Issue, sollte ein neuere Branch auf der Basis von document angelegt werden, um die komplexen Properties in einzelnen PRs prüfen zu können. Andernfalls ist die Gefahr zu groß den Überblick zu verlieren. Wenn die neue Implementation von Document fertig ist, wird alles zusammen in den doctrine Branch übernommen, aber dann ist der Code bereits geprüft.

[j3nsch]

Am Anfang, für die ersten, einfachen Properties, probiere mal bitte die Set/Get-Funktionen wegzulassen und Magic-Funktionen zu verwenden. In der alten AbstractModel wird z.B. __call verwendet. Ich denke wir werden das unter Umständen brauchen, um unser eigenes Modification-Tracking umzusetzen. Für Document wird es unter Umständen später auch konfigurierbare Felder geben. Es lohnt sich also mal zu schauen, ob es bei diesem Ansatz Probleme gibt. Im Augenblick sehe ich es nicht als etwas das wir für alle Modelle machen müssen/sollten.

Die alte Funktionalität verwendete dann die entsprechenden Field-Objekte, um die Werte zu setzen oder zu holen. Jetzt würde ich die Variablen direkt verwenden, wenn keine entsprechende Funktion, set/get, vorhanden ist. Auf diese Weise, kann man die Standardverarbeitung immer mit expliziten Funktionen überschreiben.

Falls sich hier Probleme zeigen kann man darüber nachdenken die Standard-Felder und die konfigurierten Felder unterschiedlich zu behandeln.

[j3nsch]

Der document Branch wird am Anfang erst einmal eine Menge gebrochener Tests haben. Die werden wir dann schrittweise mit den anderen Issues fixen.