"Die Datenbank sollte geupdated werden" verschwindet nicht

[kellermann]

Hallo liebes Forum,

ich erhalte immer wieder die bekannte Nachricht, dass die DB ein Update ben�tigt. Ich kann meine CC-Konfiguration ausw�hlen und auf Ausf�hren klicken. Dann wird mir angezeigt, dass Datenbankfelder bearbeitet wurden:



Allerdings taucht die Nachricht immer wieder auf. Cache, und User Session-Daten mehrfach geleert.

Kann es denn sein, dass die �nderungen von der DB nicht umgesetzt oder r�ckg�ngig gemacht werden?

�ber das Install-Tool sehe ich die �nderungen nicht.

Gr��e aus dem M�nsterland!

[Tim]

Wenn du die �nderungen im Install-Tool nicht siehst, wo siehst du sie denn?

[kellermann]

Direkt im Contao-Backend. �ber euer Plugin. Mit dem Install-Tool meine ich /contao/install

[Tim]

Direkt im Contao-Backend. �ber euer Plugin. Mit dem Install-Tool meine ich /contao/install

Deaktiviere mal den DCA-Cache von CC in den Systemeinstellungen. Ich kenne das Problem in einigen sehr seltenen F�llen, wenn sich die Contao Version ge�ndert hat. Die Aufforderung ist imgrunde nichts sagend, die changes laufen auf identische Felddefinitionen.

Welche �nderungen hat du denn vorher ausgef�hrt am System, dass es nun zu diesen Meldungen kommt?

[denniserdmann]

Moin Tim,

ich hake hier mal ein, weil ich das gleiche Problem mit den nicht verschwindenden Hinweisen habe.

Ich habe ein Upgrade von 4.9 auf 4.13 durchgef�hrt und dabei auch CC/CE auf 4.5.8 aktualisiert. Den von dir erw�hnten DCA-Cache in den CC Einstellungen habe ich ebenfalls deaktiviert, das �ndert aber nichts. Einziger Unterschied zu kellermann: Bei mir sind die �nderungen auch im Installtool zu sehen.

Hier ein Beispiel:

ALTER TABLE cc_bsptabelle CHANGE pid `pid` int(10) unsigned NOT NULL default '0';

Zur Installation:

• Contao 4.13.20
• CE/CC 4.5.8
• MySQL 8

Kannst du das Problem nachvollziehen? Gibt es zur Not einen vorl�ufigen Workaround?

Viele Gr��e,
Dennis

[Tim]

Von 4.9 auf 4.13 hat Contao einige Doctrine �nderungen mitgemacht in der DB. Event. Mysql auf 5 setzen. Zur Not direkt in PHPmyadmin �ndern.

[denniserdmann]

Zur Not direkt in PHPmyadmin �ndern

Das habe ich bereits versucht. Aber den obigen Befehl in PHPMyAdmin zu verwenden, hat nichts ge�ndert (was m�sste ich stattdessen verwenden?). Da das Projekt mit Contao 4.9 bereits auf MySQL 8 lief, f�llt es mir schwer, nun auf Version 5 zur�ckzugehen.

Ich wundere mich, dass das Problem anscheinend nur bei so wenigen Personen auftritt. Ich w�rde eigentlich davon ausgehen, dass alle Installationen mit 4.13 in einer halbwegs aktuellen Serverumgebung betroffen sind.

Vielleicht hast du noch eine Idee, ansonsten w�rde ich kurzfristig die Fehlermeldung unterdr�cken und abwarten bis das Problem eurerseits mit einem Update gel�st wurde.

Viele Gr��e,
Dennis

[Tim]

Ohne konkrete Anhaltspunkte kann ich kein Update angehen . Es gab immer mal F�lle, wo vermeintliche Feld�nderungen ausgef�hrt werden sollten. Es waren immer Einzelf�lle.

Leg mal ein neues Feld an und schau mal in phpmyadmin in welcher Form sich das neue Feld zu den hier bestehenden unterscheidet. Event. ist es die Kollation, die sich im Laufe von Contao Hauptversionen ebenfalls oft ge�ndert hat und durch das Install-Tool nicht ge�ndert wird.

[denniserdmann]

Das ist ein guter Hinweis.

Mir ist gerade aufgefallen, dass es sich bei allen Feldern um Nummernfelder handelt. Die meisten legt der CC an und ich habe keinen Einfluss darauf:

ALTER TABLE cc_bsptabelle CHANGE pid `pid` int(10) unsigned NOT NULL default '0';
ALTER TABLE cc_bsptabelle CHANGE tstamp `tstamp` int(10) unsigned NOT NULL default '0';
ALTER TABLE cc_bsptabelle CHANGE sorting `sorting` int(10) unsigned NOT NULL default '0';

Mein eigenes Feld ist genauso wie das soeben neu erstellte Feld my_sorting betroffen:

ALTER TABLE cc_bsptabelle CHANGE cc_sorting `cc_sorting` int(10) unsigned NOT NULL default '0';
ALTER TABLE cc_bsptabelle CHANGE my_sorting `my_sorting` int(10) unsigned NOT NULL default '0';

Es gibt also keinen Unterschied zwischen einem bereits erstellten Feld und einen neu hinzugef�gten Feld. Sie haben beide das gleiche Problem.

[Tim]

Ich glaube Mysql 8 handelt integer Felder anders. Ich schau mal, dass ich auf einen mysql 8 server komme. Unsere Testserver sind all-inkl. Dort ist Mariadb im Einsatz.

[denniserdmann]

Wenn ich das richtig sehe, dann kommt MySQL 8 nicht mit dem int(10) zurecht. Ich habe testweise mal bei den betroffenen Feldern in der DCAHelper.php die (10) entfernt. Dadurch verschwinden die DB-Update Aufforderungen. Damit hast du zumindest einen Anhaltspunkt.

Wie gesagt, ich denke das das Problem in allen MySQL 8 Installationen auftreten wird.

[Tim]

Wenn ich das richtig sehe, dann kommt MySQL 8 nicht mit dem int(10) zurecht. Ich habe testweise mal bei den betroffenen Feldern in der DCAHelper.php die (10) entfernt. Dadurch verschwinden die DB-Update Aufforderungen. Damit hast du zumindest einen Anhaltspunkt.

Wie gesagt, ich denke das das Problem in allen MySQL 8 Installationen auftreten wird.

Ja, integer sind anders unter Mysql 8. Wie setzt denn Contao selbst integer Felder unter M8 z.B. tl_page.sorting?

[denniserdmann]

Das ist sehr merkw�rdig. Die Anweisungen scheinen identisch mit deinen zu sein, aber f�r die Contao Felder bekomme ich keine Hinweise, dass sie weiterhin aktualisiert werden m�ssen. Ich vermute, dass ich sie beim Update auf 4.13 bestimmt anpassen musste, aber danach tauchen sie nicht mehr im Installtool auf.

[Tim]

Das ist sehr merkw�rdig. Die Anweisungen scheinen identisch mit deinen zu sein, aber f�r die Contao Felder bekomme ich keine Hinweise, dass sie weiterhin aktualisiert werden m�ssen. Ich vermute, dass ich sie beim Update auf 4.13 bestimmt anpassen musste, aber danach tauchen sie nicht mehr im Installtool auf.

Vielleicht werden die Definitionen noch einmal intern umgewandelt und angepasst. Hast du mal versucht die SQL-DCA-Felddefinitionen in die dcaconfig.php zu setzen zum Test. Die m�sste Contao abwandeln.

[denniserdmann]

Ich verstehe nicht ganz, was du meinst. Aber ich habe nochmal ein paar Tests gemacht, und dabei gesehen, dass normale DB-�nderungen anders aussehen, als die f�r CC. Vielleicht hilft dir das weiter:

So sieht die Anweisung f�r den CC aus:

ALTER TABLE cc_bsptabelle CHANGE sorting `sorting` int(10) unsigned NOT NULL default '0';

und so f�r tl_page:

ALTER TABLE tl_page CHANGE sorting sorting INT UNSIGNED DEFAULT 0 NOT NULL

(keine Backticks)