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.

[matthias-ronge]

Die Verwendung von KI ist eine interessante Frage. Ich denke, dass man als Programmierer auch Hilfe von KI in Anspruch nehmen kann, aber es bleibt die Verantwortung des Programmierers, der die Commits erstellt, zu verstehen, was sie tun, und es liegt in seiner Verantwortung, dass sie das tun, was sie tun sollen. Wenn ein Bug darin ist, muss man immer noch verstehen können, warum, um ihn beheben zu können. Aber es kann hilfreich sein, dass die KI möglicherweise eine Syntax verwendet, die man nicht kannte, und einen dabei unterstützt, die richtigen Anweisungen zu finden, und zu verstehen, wie man sie nutzen kann.

Übrigens würde ich es vermeiden, eine Prozedur zu definieren und sie später zu löschen, und lieber nur die einfachen Anweisungen aufschreiben. Wenn die Ausführung des SQL aus irgendeinem Grund abbricht, bleibt die Prozedur für immer in der Datenbank, und Jahre später, wenn ein Server migriert wird, fragt sich jemand, wofür sie gebraucht wird.

Ich frage mich, warum deine Datenbank überhaupt noch Tabellen mit Großbuchstaben enthält, meine nicht (und das entspricht den Annotationen in den Bean-Klassen):

mysql> show tables;
+-----------------------------------+
| Tables_in_kitodo                  |
+-----------------------------------+
| authority                         |
| batch                             |
| batch_x_process                   |
| client                            |
| client_x_listcolumn               |
| client_x_user                     |
| comment                           |
| dataeditor_setting                |
| docket                            |
| filter                            |
| flyway_schema_history             |
| folder                            |
| importconfiguration               |
| importconfiguration_x_mappingfile |
| ldapgroup                         |
| ldapserver                        |
| listcolumn                        |
| mappingfile                       |
| process                           |
| process_x_property                |
| project                           |
| project_x_template                |
| project_x_user                    |
| property                          |
| role                              |
| role_x_authority                  |
| ruleset                           |
| searchfield                       |
| task                              |
| task_x_role                       |
| template                          |
| template_x_property               |
| urlparameter                      |
| user                              |
| user_x_role                       |
| workflow                          |
| workflowcondition                 |
| workpiece_x_property              |
+-----------------------------------+
38 rows in set (0,01 sec)

Kann die Datenbank kitodo fremde Tabellen enthalten? Ja, das kann sie. Beginnend mit Tabelle flyway_schema_history, die nicht wirklich Teil der Anwendung selbst ist. Außerdem kannte ich früher Server, wo das der Fall war (für Kundenerweiterungen), oder einfach nur durch einen Fehler, oder faule Administratoren …

Die Copyright-Frage kann ich überhaupt nicht beurteilen.

(Bezüglich der Groß- und Kleinschreibung möchte ich hinzufügen, dass der Windows Explorer seine Anzeige manchmal nicht richtig aktualisiert, wenn sich nur die Groß- und Kleinschreibung eines Dateinamens ändert. Der Dateiname wird auf der Festplatte geändert. Das ist hier ab vom Thema, aber ich erwähne es, da es in dem Kontext eine Quelle für Verwirrung sein kann.)

[matthias-ronge]

Please check again whether there are any tables with capital letters in the database at all. In my case, this is not the case. Then, this migration would at least be superfluous (and perhaps better in the kitodo-contrib repository).

[stweil]

Ich frage mich, warum deine Datenbank überhaupt noch Tabellen mit Großbuchstaben enthält, meine nicht (und das entspricht den Annotationen in den Bean-Klassen):

Das ist momentan der Normalfall auf macOS, wenn man dort Kitodo neu installiert (siehe CI Demo). Gleiches gilt vermutlich für Windows (abhängig davon, wie dort mariaDB läuft). Und bevor jetzt jemand einwendet, dass weder macOS noch Windows die unterstützten Laufzeitumgebungen sind: ich entwickle unter macOS, und da ist es einfach schön, wenn das ohne spezielle Klimmzüge funktioniert.

[stweil]

Kann die Datenbank kitodo fremde Tabellen enthalten? Ja, das kann sie. Beginnend mit Tabelle flyway_schema_history, die nicht wirklich Teil der Anwendung selbst ist. Außerdem kannte ich früher Server, wo das der Fall war (für Kundenerweiterungen), oder einfach nur durch einen Fehler, oder faule Administratoren …

Die aktuelle Fassung meines Commits berücksichtigt das und gibt die fünf Tabellen, deren Namen zu korrigieren sind, explizit an.

[stweil]

Wenn die Ausführung des SQL aus irgendeinem Grund abbricht, bleibt die Prozedur für immer in der Datenbank, und Jahre später, wenn ein Server migriert wird, fragt sich jemand, wofür sie gebraucht wird.

Würde dieser Migrationsschritt auch nach einem (unwahrscheinlichen) Abbruch als "durchgeführt" registriert werden? Oder würde spätestens die nächste Migration mit flyway den Schritt wiederholen und dabei die Prozedur entfernen? Unabhängig davon ist der Name der Prozedur "rename_tables_to_lowercase" ziemlich eindeutig.