[Michael]

Hallo, beim Update meiner Testumgebung auf die 11.0.1 bekomme ich bei dem DBUpdate Script einen Fehler:

————— snip —————
otobo@server:~/scripts$ ./DBUpdate-to-11.0.pl

Migration started …
Executing task ‘Add frontend_mask_definition table.’ …
Executing task ‘Add set and value indices to dynamic_field_value; change its id to BIGINT.’ …
DBD::mysql::db do failed: All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead at /opt/otobo/Kernel/System/DB.pm line 586.
ERROR: OTOBO-DBUpdate-to-11.0.pl-5 Perl: 5.36.0 OS: linux Time: Fri May 17 08:15:58 2024

Message: All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead, SQL: ‘ALTER TABLE dynamic_field_value CHANGE id id BIGINT NULL’

Traceback (12749):
Module: scripts::DBUpdateTo11_0::Base::ExecuteXMLDBString Line: 418
Module: scripts::DBUpdateTo11_0::Base::ExecuteXMLDBArray Line: 366
Module: scripts::DBUpdateTo11_0::DBUpdateDynamicFieldValue::Run Line: 60
Module: scripts::DBUpdateTo11_0::Run Line: 109
Module: ./DBUpdate-to-11.0.pl Line: 43

ERROR: OTOBO-DBUpdate-to-11.0.pl-5 Perl: 5.36.0 OS: linux Time: Fri May 17 08:15:58 2024

Message: Error during execution of ‘ALTER TABLE dynamic_field_value CHANGE id id BIGINT NULL’!

Traceback (12749):
Module: scripts::DBUpdateTo11_0::Base::ExecuteXMLDBString Line: 421
Module: scripts::DBUpdateTo11_0::Base::ExecuteXMLDBArray Line: 366
Module: scripts::DBUpdateTo11_0::DBUpdateDynamicFieldValue::Run Line: 60
Module: scripts::DBUpdateTo11_0::Run Line: 109
Module: ./DBUpdate-to-11.0.pl Line: 43
————— snip —————

Wenn ich die Änderung händisch durchführe und NOT NULL im Statement verwende, dann läuft es durch, macht ja bei einer ID-Spalte auch Sinn vermutlich. Kann das ggfs. ein Bug sein?

[Chris Ru]

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

[Michael]

Als Workaround habe ich das relevante Statement in der Datei scripts/DBUpdateTo11_0/DBUpdateDynamicFieldValue.pm entfernt und vor Scriptausführung manuell auf der DB durchgeführt.

mysql> ALTER TABLE dynamic_field_value CHANGE id id BIGINT NOT NULL AUTO_INCREMENT;

Dann das DB-Update Script ausgeführt und die Umgebung funktioniert.

 

Vermutlich muss in der o.g. Datei für den ColumnChange nur noch ein Parameter für “NOT NULL” eingefügt werden, da bin ich aber nicht so bewandert. Hilfreiche Tips sind gerne genommen.

[Michael]

Screenshot ist nicht übergekommen, daher hier nochmal ein Versuch.. Das Portal unter neuer Domain ist teilweise noch etwas buggy, Editieren des vorherigen Beitrags ist auch nicht möglich.

[Michael]

Hm, anscheinend gehen gar keine Screenshots, daher hier der Block als Plaintext

my ( $Self, %Param ) = @_;

# one statement per column, so that an already existing column does not abort the update
my @XMLStrings = (
‘<TableAlter Name=”dynamic_field_value”>
<ColumnAdd Name=”index_value” Required=”false” Type=”SMALLINT” />
</TableAlter>’,
‘<TableAlter Name=”dynamic_field_value”>
<ColumnAdd Name=”index_set” Required=”false” Type=”SMALLINT” />
</TableAlter>’,
‘<TableAlter Name=”dynamic_field_value”>
<ColumnChange NameOld=”id” NameNew=”id” Required=”true” PrimaryKey=”true” AutoIncrement=”true” Type=”BIGINT” />
</TableAlter>’,
);

return unless $Self->ExecuteXMLDBArray(
XMLArray => \@XMLStrings,
);

return 1;
}

[Stefan Rother]

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

[Sven Oesterling]

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

[Sven Oesterling]

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

[Chris Ru]

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.

[Michael]

Hi Sven, sorry aber Freitag war ich schon im Wochenende :-)

MySQL Version ist bei mir die gleiche:
mysql Ver 8.0.36 for Linux on x86_64 (MySQL Community Server – GPL)

Wobei ich auch vermute, dass das Problem bereits vor dem Query zu suchen ist, schließlich fehlt hier das entsprechende NOT in der Anfrage, sodass es ein Thema der Query-Generierung sein sollte.

[Sven Oesterling]

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

[bes]

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

 

 

 

[bes]

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.

[Autor]

Beiträge