Migrate table names with uppercase to lowercase names (macOS, Windows)

[stweil]

For case sensitive filesystems which are typically used by Linux such renames were already done in earlier migration steps, but those steps have no effect on macOS and Windows.

The new SQL migration code renames any table name with uppercase letters to a lowercase table name.

The script was created by Claude.AI.

Fixes: #6139

[henning-gerhardt]

The review is in German as I don't want that translations errors are resulting in discussions which are not needed.

1. Dass das Skript mit Hilfe von oder komplett durch KI erzeugt wurde, sollte als Anlass genommen werden, dass sich der Verein oder zumindest das Release Management dazu positioniert, wie mit KI unterstützten oder erzeugten Code im Projekt umgegangen wird. In den Coding Guidelines ist dies nicht explizit definiert, da zum letzten Zeitpunkt der Aktualisierung der Coding Guidelines die KI nicht so stark verbreitet war als es mittlerweile der Fall ist. KI hat unbestreitbar Vorteile aber auch genügend Nachteile (bspw. Verstöße gegen bspw. Urheber- und / oder Lizenzrecht), so dass der Einsatz gut abgewogen und dies auch klar definiert sein sollte, wann und wie KI genutzt werden darf und sollte.

2. Die erzeugte Procedure funktioniert auf case-sensitive Systemen nicht, d.h. Tabellen mit Großbuchstaben werden nicht umbenannt.

3. Die Procedure benennt alle bestehenden Tabellen, Views und Procedures in der genutzten Datenbank um, egal ob diese aus der Anwendung Kitodo.Production heraus genutzt werden oder nicht. D.h. es werden auch anwendungsfremde Tabellen, Views und Procedures umbenannt, die nicht zur Anwendung gehören aber aus anderen Gründen (Analyse, Reporting, Datenanreicherung, ...) in der gleichen Datenbank wie die Tabellen der Anwendung existieren. Bisher war dies weder ein Problem noch sollte dies auch zukünftig ein Problem sein, dass neben den Tabellen der Anwendung selbst noch weitere Tabellen, Views und Procedures existieren. Daher sollte die Procedure so angepasst werden, dass nur die Tabellen der Anwendung zum Ausführungszeitpunkt umbenannt werden, aber andere Tabellen, Views und Procedures weiterhin unter ihren bestehenden Namen bleiben.

[stweil]

Zu 1. Und was folgt daraus jetzt? Code, der mit Claude.AI erzeugt wurde, darf frei verwendet werden. Die Verantwortung, dass er korrekt ist, trägt man selbst. Das ist nicht anders als bisher, wo man häufig Codeteile durch "Googeln" zusammengesucht hat.

Zu 2. Hast du es ausprobiert? Warum sollte der Code z. B. unter Linux nicht funktionieren?

Zu 3. Behandelt werden alle Objekte in INFORMATION_SCHEMA.TABLES der aktuellen Datenbank (wie bei anderen Migrationsskripten auch). Erwarten wir, dass die Kitodo-Datenbank applikationsfremde Objekte enthält? Das würde ich grundsätzlich verbieten, und falls es sie dennoch geben sollte, hätten sie vermutlich das gleiche Problem mit Groß-/Kleinschreibung.

[stweil]

Hier kann man – wenn dies tatsächlich erforderlich ist – alternativ oder als weitere Bedingung ergänzen, dass nur ausgewählte Tabellen umbenannt werden: AND TABLE_NAME IN ('Tabelle1', 'Tabelle2', ...) (siehe Diskussionsbeitrag, wo angemerkt wird, dass die Kitodo-Datenbank auch Tabellen enthalten kann, die nicht zu Kitodo gehören). Ebenfalls möglich ist die Beschränkung auf Tabellen mit AND TABLE_TYPE = 'BASE TABLE'.

[henning-gerhardt]

Zu 2. Hast du es ausprobiert? Warum sollte der Code z. B. unter Linux nicht funktionieren?

Ja, dass habe ich und sonst hätte ich es nicht geschrieben. Da wir an der SLUB von dieser Änderung betroffen wären. Ich zeige aber mit Absicht nicht den Fehler auf, warum dies nicht funktioniert.

Zu 3. Behandelt werden alle tables der aktuellen Datenbank (wie bei anderen Migrationsskripten auch).

Das ist keine korrekte Aussage. Alle bisherigen Migrationsskripte haben nur die gewählten / explizit genannten Tabellen der Anwendung migriert und nicht pauschal alle, wie es hier in diesem Fall vorliegt.

Erwarten wir, dass die Kitodo-Datenbank applikationsfremde tables enthält?

Dazu gibt es keine Aussage bisher und bis zu diesem PR war dies auch nicht notwendig, eine solche Aussage zu treffen, da jeweils nur die anwendungsspezifischen Tabellen geändert wurden und nicht pauschal alles. Dies jetzt in Frage zu stellen, halte ich für falsch und ist auch nicht zwingend notwendig

Das würde ich grundsätzlich verbieten

Das ist deine Ansicht, ich sehe bisher keine Gründe, warum dies verboten sein sollte. Das die Pflege von anwendungsfremden Tabellen, Views und Procedures bei jeden selbst liegt, steht gar nicht zur Diskussion. Jedoch eine Änderung bzw. Anpassung dieser Tabellen, Views und Procedures sollte nicht durch die Migrationsskripte der Anwendung passieren sondern durch die jeweiligen Administratoren selbst. Nur diese wissen, wie die Anpassungen durchzuführen sind.

und falls es sie dennoch geben sollte, hätten sie vermutlich das gleiche Problem mit Groß-/Kleinschreibung.

Da dieser PR wohl auch bei Systemen eingesetzt werden soll, die Groß- und Kleinschreibung unterscheiden und wo es vermutlich nicht einmal notwendig ist, kommt es erst durch diesen PR zu Problemen, wenn anwendungsfremde Tabellen, Views und Procedures umbenannt werden. Ich erwarte von einer Migration, dass die anwendungsspezifschen Daten geändert werden aber beim besten Willen keine anwendungsfremden Daten.

[stweil]

Anmerkung 2. ist jetzt korrigiert, und bezüglich 3. habe ich auf "BASE TABLES" eingeschränkt, so dass andere Objekte nicht berührt werden. Haben wir eine Liste aller Tabellen, die behandelt werden sollen? Dann könnte ich diese noch ergänzen.

[henning-gerhardt]

Haben wir eine Liste aller Tabellen, die behandelt werden sollen? Dann könnte ich diese noch ergänzen.

Prinzipiell könnte jede bestehende Tabelle der Anwendung betroffen sein, jedoch ist die Anzahl deutlich geringer und diese sind doch in #4412 genannt. Als weitere Quellen könnten #6139 , #4412 und #3998 dienen.

[stweil]

Mit dem letzten Commit wird die Umbenennung auf die fünf bekannten Tabellen beschränkt, die unter macOS sonst einen Namen mit Großbuchstaben hätten.