Mögliche Werte für Feld PublicationState anpassen

[j3nsch]

Momentan kann das Feld PublicationState nicht auf NULL gesetzt werden und ist daher in den meisten Fällen auf draft gesetzt. Bislang wurde das Feld auch nicht verwendet. Das soll sich jetzt ändern (Siehe auch OPUS4/application#814).

Als Werte sollten ansonsten die von DINI definierten möglich sein. Diese Werte können dann direkt beim XMetaDissPlus Export verwendet werden.

[j3nsch]

Unit Tests müssen noch hinzugefügt werden, um zu zeigen, dass das Feld PublicationState auch NULL speichern kann und wie es mit ungültigen Werten umgeht.

[j3nsch]

Die Datenbank scheint ungültige Werte als NULL bzw. leeren String abzuspeichern, aber der OPUS 4 Code merkt, dass der gespeicherte Werte, nicht dem ursprünglichen Wert entspricht und wirft eine Exception. Normalerweise sollte es einen Fehler geben, wenn versucht wird ungültige Werte zu speichern. Ob uns das hier Probleme bereitet hängt davon ab, wie wir den Update-Process gestalten.

[alw-bsz]

Momentan kann das Feld PublicationState nicht auf NULL gesetzt werden und ist daher in den meisten Fällen auf draft gesetzt. Bislang wurde das Feld auch nicht verwendet. Das soll sich jetzt ändern (Siehe auch OPUS4/application#814).

Als Werte sollten ansonsten die von DINI definierten möglich sein. Diese Werte können dann direkt beim XMetaDissPlus Export verwendet werden.

Die Sets/Werte sollten bei allen Ausgabeformaten über OAI-PMH verfügbar sein, nicht nur in XMetaDissPlus (DINI spezifiziert das Set für das Format oai_dc).

[j3nsch]

Die Sets/Werte sollten bei allen Ausgabeformaten über OAI-PMH verfügbar sein, nicht nur in XMetaDissPlus (DINI spezifiziert das Set für das Format oai_dc).

Ja, gut. Die Sets sind sowieso unabhängig vom Ausgabeformat. Worüber ich mir mehr Gedanken mache, ist die Frage, ob wir intern die DINI-Werte verwenden wollen oder erst bei der Ausgabe eine Übersetzung stattfindet. Bislang gab es ja intern "submitted" und jetzt heißt es "submittedVersion". Was sinnvoll ist, hängt unter anderem davon ab, bei welchen Ausgabeformaten die Werte direkt verwendet werden können. Müssen wir die Werte für einzelne Formate übersetzen? Wenn ja, dann könnten wir auch bei "submitted" bleiben und sparen uns Issues beim Update.

[alw-bsz]

Ja, gut. Die Sets sind sowieso unabhängig vom Ausgabeformat.

Das hatte ich vermutet, aber ich wollte es sicherheitshalber festgehalten haben ;).

Ich denke, Übersetzungen sind sinnvoll. Derzeit ist eine Übersetzung für einzelne Formate zwar nicht nötig, ich würde aber nicht ausschließen, dass das früher oder später relevant werden könnte.

[j3nsch]

Wenn wir momentan noch keine Übersetzungen brauchen, sondern beim Export direkt "submittedVersion", "acceptedVersion" usw. verwenden können, dann macht es mehr Sinn die aktuell in der Datenbank erlaubten Werte zu ändern. Um Probleme zu vermeiden, sollten alle in der Datenbank existierenden Werte während des Datenbank-Updates auf die neuen Versionen aktualisiert werden, also "submitted" wird zu "submittedVersion". Dadurch sparen wir uns PHP Skripte, die vor der Aktualisierung des Datenbank-Schemas ausgeführt werden müssen.

[j3nsch]

Ich hatte noch einen Denkfehler. Wir können die vorhanden Werte natürlich nicht vor und auch nicht nach der Änderung im Schema umschreiben, weil als ENUM ungültige Werte sofort entfernt werden. Ich denke wir müssen beim Schema-Update in einem Zwischenschritt, die alten und die neuen Werte erlauben, dann die Dokumente aktualisieren, und am Ende die alten ENUM-Werte entfernen.

[j3nsch]

Beim Schema-Update werden die alten Einträge jetzt umgewandelt.

[j3nsch]

In einem weiteren Update-Schritt werden zusätzliche Werte zum ENUM für PublicationState hinzugefügt, um das COAR-Vokabular zu unterstützen.