Bei mir kommt das gleiche. Update von 10.1 auf 11.0.1. Hat jemand eine Lösung?

Hallo Michael,

ich gebe es mal an unsere Entwicklung weiter, denn ich verstehe nicht ganz wie es dazu kommen kann.

Und um das Forum Thema, werde ich mich auch kümmern.

Danke für Dein Feedback!

Stefan Rother

Team OTOBO

Hallo Michael,

könntest du uns bitte die Version deiner MySQL/MariaDB schicken? („mysql –version“)
Das Problem ist so bei uns nicht nachvollziehbar, die von dir kopierten Zeilen sind aufjedenfall aber richtig. Das „Required=true“ sollte das NOT NULL eigentlich setzen. (Der Wechsel auf bigint wird auf den meisten Systemen vermutlich nie nötig sein, d.h. weiter testen kannst du aufjedenfall ohne den Teil des scripts, genau so, wie von dir geschrieben, aber wir werden das natürlich angucken.)

Danke schonmal,

Sven

(Ich kann meinen Artikel gerade nicht bearbeiten, das sind zwei minus vor dem version.)

Da ich das gleiche Problem habe, Antworte ich einfach mal:

mysql Ver 8.0.36-0ubuntu0.22.04.1 for Linux on x86_64 ((Ubuntu))

Aber an sich ist das Problem ja nicht mysql, sondern das SQL was generiert wird. Da fehlt das NOT NULL schon, was dann den Fehler im Mysql-Server verursacht.

Guten Morgen,

jain, ihr habt Recht, in Bezug auf euer Setup, aber da läuft eigentlich ein ganzer Satz an SQL-Statements durch:
ALTER TABLE dynamic_field_value CHANGE id id BIGINT NULL
ALTER TABLE dynamic_field_value CHANGE id id BIGINT DEFAULT NULL
UPDATE dynamic_field_value SET id = 0 WHERE id IS NULL
ALTER TABLE dynamic_field_value CHANGE id id BIGINT NOT NULL AUTO_INCREMENT

Das ist so gebaut, um etwas breiter auch Fälle abzudecken, wo es nicht um einen primary key geht, wo die Tabelle davor vllt nicht „NOT NULL“ war, so dass dann auch aufgefüllt wird etc.. Bei euch steigt er halt gleich beim ersten aus. Wir kommen auch grad erst aus dem langen Wochenende, aber mir sieht es auf den ersten Blick so aus, als würden manche SQL-Versionen das einfach mitmachen, und andere nicht. Da das eine ziemlich grundlegende Routine ist, müssen wir hier noch ein bisschen gucken.

Danke, Sven

Hallo,

ich habe das auch nochmal nachvollzogen. Sven hat ja bereits geschrieben dass im Endeffekt mehrere SQL Befehle ausgeführt werden. Ziel ist es möglichst viele Fälle abzufackeln. D.h. zuerst erlaubt man NULL-Werte in der Spalte, damit man im nächsten Schritt einen Default-Wert setzen kann.  Wobei der Default des Defaultwertes entweder die Zahl 0 oder der Leerstring ist. Der Fall dass die Spalte NOT NULL ist, aber keinen Default Wert hat, ist nicht vorgesehen.

Problematisch wird es wenn die Spalte bereits ein Primärschlüssel ist. Der erste Befehl

ALTER TABLE dynamic_field_value CHANGE id id BIGINT NULL

macht da keinen Sinn, da ein Primärschlüssel nicht NULL seid darf. Dabei verhalten sich anscheinend die verschiedenen Datenbank-Versionen unterschiedlich. Ich habe mit MariaDB 10.5.25 getestet. Dort wird die Deklaration ‚NULL‘ einfach ignoriert und das Feld bleibt auf ‚NOT NULL‘. Dieses Verhalten könnte man als Bug einstufen. Siehe https://mariadb.com/kb/en/primary-keys-with-nullable-columns/ . MySQL 8 liefert nachvollziehbarerweise den Fehler „All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead“.

Das Problem könnte man mit einer Anpassung im mysql Treiber, https://github.com/RotherOSS/otobo/blob/66090f514ea1ed82daed2222beac3331dafa3823/Kernel/System/DB/mysql.pm#L396, angehen. Das wäre jedoch ein tiefer Eingriff der auch Schaden anrichten kann. Einfacher erscheint es mir den Befehl

ALTER TABLE dynamic_field_value CHANGE id id BIGINT NOT NULL AUTO_INCREMENT;

im Update-Skript hart zu verdrahten. Wobei zumindest der Typ abhängig von der Datenbank ermittelt werden sollte.

Viele Grüße,

Bernhard

Hallo,

in OTOBO 11.0.2 sollte das Problem behoben sein. Siehe https://github.com/RotherOSS/otobo/issues/3414 . Im Endeffekt wird dann nur noch der funktionierende SQL-Befehl

ALTER TABLE dynamic_field_value CHANGE id id BIGINT NOT NULL AUTO_INCREMENT

ausgeführt.