MySQL Fehler #1118 - Row size too large

Hallo liebe Community,

ich habe heute die Erweiterung contao-isotope-bundle von heimrichhanot installiert. Das ging auch alles ganz gut, aber als ich die Datenbank aktualisieren wollte, brach dies mit einem Fehler ab. Also nochmal versucht - wieder Fehler. In den Logs geschaut, erscheint folgende Meldung:

Code:

---

SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126.

---

Die Erweiterungen möchten in der Tabelle tl_module offensichtlich noch ein paar Spalten anfügen, aber die folgenden Befehle können nicht mehr ausgeführt werden (ein Großteil ist aber bereits durch! Aktuell sind in der tl_module 374 Spalten.) :

Code:

---

ALTER TABLE tl_module ADD formHybridEditableRequired BLOB DEFAULT NULL
ALTER TABLE tl_module ADD formHybridAddEditableRequired CHAR(1) DEFAULT '' NOT NULL
ALTER TABLE tl_module ADD formHybridEditable BLOB DEFAULT NULL
ALTER TABLE tl_module ADD formHybridForcePaletteRelation CHAR(1) DEFAULT '1' NOT NULL
ALTER TABLE tl_module ADD formHybridViewMode VARCHAR(10) DEFAULT 'default' NOT NULL
ALTER TABLE tl_module ADD formHybridDataContainer VARCHAR(64) DEFAULT '' NOT NULL
ALTER TABLE tl_module ADD hideAutoItem CHAR(1) DEFAULT '' NOT NULL
ALTER TABLE tl_module ADD block INT UNSIGNED DEFAULT 0 NOT NULL

---

Dies scheint ja ein MySQL Problem zu sein. Hat das jemand von euch schon mal gehabt? Anscheinend liegt es daran, dass tl_module eine InnoDB ist. Mit anderen Tabellenformaten kann man wohl von 8k erweitern auf 64k, aber ich bin mir nicht sicher, ob ich das Format einfach so ändern "darf".

Bin für Tipps dankbar.

Danke für eure Hilfe und viele Grüße
Julian

Bei tl_module hatte ich das noch nicht. Aber tl_content habe ich zuletzt Ende 2017 an die Grenze gebracht, als ich das ProTheme installierte was unzählige neue Spalten für tl_content mitbringt. Ich habe alle überflüssigen Inhaltselemente des Themes gelöscht oder die Spalten von varchar auf text geändert.

Hm, bei content macht das sicherlich auch Sinn, aber bei Module fliegt man raus, sobald die PHP Abfrage die entsprechende Spalte nicht findet, und dann müsste ich ja auch noch die Abfragen in den Modulen anpassen. Davon abgesehen, dass ich nicht weiß, welche Module nun wirklich welche Spalten unbedingt benötigen. Die Chance, dass ich irgendwann ein Modul in einer Form bearbeite, dass es gerade auf die Spalten zugreifen muss, die ich gelöscht habe, ist doch relativ groß, da ich die Module ja nicht ohne Grund installiert habe.

Das bedeutet aber umgekehrt auch, dass ich keinerlei Module mehr installieren kann, welche die tl_module anfassen. Das ist nun auch nicht unbedingt zufriedenstellend.

Und ich würde mal glatt vermuten, dass die Programmierer auch nicht happy darüber sein werden, wenn ich sie bitte ihre 25 oder wieviele auch immer Spalten in eine extra Tabelle auszulagern, und nur eine ID in tl_module zu packen.

Gibt es da wirklich keine andere Möglichkeit?

Aus Interesse: Warum nicht das Original installieren?

Zitat:

---

Zitat von planepix

Aus Interesse: Warum nicht das Original installieren?

---

Was genau meinst du? Isotope ist installiert. Das Bundle möchte ich, da ich bestimmte Funktionalitäten gern zusätzlich zu Isotope möchte. ;)

Ok, verstehe. Ich hatte es nicht im Detail vorher angesehen. Dachte das ersetzt Isotope… Somit weiter Erfolg beim Debuggen!

Wenn Du die Module, die soviel Spalten verbraten behalten willst, dann ändere das SQL der betreffenden Module von varchar auf text um (über eigenes DCA). So bekommst Du wieder reichlich Platz in der tl_module, weil text-Spalten nicht mitgezählt werden.

text sollte doch größer als varchar(255) sein?

Text wird aber nicht direkt inline in der row gespeichert wie varchar. Bei text wird nur ein Pointer darauf inline gespeichert. Deswegen wird natürlich durch ein varchar(255) wesentlich mehr Platz belegt.

Achja, stimmt :).

Zitat:

---

Zitat von Samson1964

Wenn Du die Module, die soviel Spalten verbraten behalten willst, dann ändere das SQL der betreffenden Module von varchar auf text um (über eigenes DCA). So bekommst Du wieder reichlich Platz in der tl_module, weil text-Spalten nicht mitgezählt werden.

---

Hm, mit DCA hab ich noch nie gearbeitet... aber egal... ich hab mal aus Spaß an der Freude die tl_module direkt bearbeitet: kein Unterschied. Obwohl ich gut 20 Spalten von varchar(255) auf text geändert habe, kann ich keine neuen Spalten hinzufügen. Es scheint den Spalten also ziemlich egal zu sein, "was" sie sind, da die Tabelle offensichtlich im Kopf dadurch nicht kleiner wird. Aber selbst wenn ich 24 oder 32 oder 64 Spalten ändern muss, damit ich eine weitere Spalte hinzubekommen kann, brauche ich doch deutlich mehr Platz, und habe weiterhin das Problem, keine weiteren Module installieren zu können, selbst wenn ich mal wollte.

Kann ich irgendwie "updatesicher" die Spalten in neue Tabellen umziehen, oder können das nur die jeweiligen Entwickler?

Grüße
Julian

Wenn Du die Spalten änderst, z.B. von

PHP-Code:

---

'sql'           => "varchar(512) NOT NULL default ''" 


---

auf

PHP-Code:

---

'sql'           => "text NULL" 


---

mußt Du das Installtool zur Aktualsierung der Datenbank aufrufen, damit die Änderungen wirksam werden.

Updatesicher kannst Du Deine Änderungen eintragen in system/config/dcaconfig.php unter Contao 3 oder in app/Resources/contao/dca/tl_module.php unter Contao 4.

Zitat:

---

Zitat von Samson1964

Wenn Du die Spalten änderst, z.B. von

PHP-Code:

---

'sql'           => "varchar(512) NOT NULL default ''" 


---

auf

PHP-Code:

---

'sql'           => "text NULL" 


---

mußt Du das Installtool zur Aktualsierung der Datenbank aufrufen, damit die Änderungen wirksam werden.

Updatesicher kannst Du Deine Änderungen eintragen in system/config/dcaconfig.php unter Contao 3 oder in app/Resources/contao/dca/tl_module.php unter Contao 4.

---

Hab ich probiert. Hat auch initial funktioniert - hab alle varchars in text "gewandelt", das hat das installtool realisiert, und umgesetzt, aber die noch fehlenden Spalten sind dennoch nicht hinzu gekommen. Stattdessen ist nun mein Composer hinüber, und will nur noch im Safe Mode starten.

Demnach habe ich jetzt mal die heimrichhanot Packages deinstalliert, und dabei festgestellt, dass anscheinend aufgrund der ganzen Abhängigkeiten über 180 neue Einträge in die tl_module gemacht wurden. Alle einzeln sind sicherlich kein Problem, aber eins ganz oben, welches so weit nach unten durchgreift, dass die tl_module "überläuft" ist natürlich unpraktisch. :(

Aber auch das behebt das Manager Problem nicht:

Code:

---

The Contao Manager detected files that look like Contao, but the Command Line Interface does not work as expected. Please choose an option to repair your installation.

---

Wenn ich dann auf "Repair" klicke, läuft alles durch, es steht überall "OK", der Manager startet nen neuen System-Check, aber bleibt wieder beim letzten Schritt hängen, mit der obigen Fehlermeldung. Hmpf.

Da ich so viel rumgeschoben und rumgebastelt habe, ist das alles aber auch nicht verwunderlich. Ärgerlich ist nur, dass ich offensichtlich keine Möglichkeit habe die heimrichhanot Pakete davon abzuhalten sich komplett in "tl_module" einzunisten, statt eine eigene Tabelle aufzumachen, oder?!

Grüße
Julian

Zitat:

---

Zitat von JooNey

Hab ich probiert.

---

Was genau hast du gemacht? Beschreibe deine Schritte im Detail.

Zitat:

---

Zitat von JooNey

Ärgerlich ist nur, dass ich offensichtlich keine Möglichkeit habe die heimrichhanot Pakete davon abzuhalten sich komplett in "tl_module" einzunisten, statt eine eigene Tabelle aufzumachen, oder?!

---

Contao bietet dafür aktuell keine Möglichkeit, nein.

Zitat:

---

Zitat von Spooky

Was genau hast du gemacht? Beschreibe deine Schritte im Detail.

---

Ich habe eine tl_module.php in app\Resources\contao\dca erstellt mit folgendem Inhalt (gekürzt):

PHP-Code:

---

<?php

$arrDca = &$GLOBALS['TL_DCA']['tl_module'];

/**
 * Fields
 */
$arrFields = [
    'formHybridDataContainer'                    => [
        'sql'       => "text NULL",
    ],
    'formHybridCustomHash'                       => [
        'sql'       => "text NULL",
    ],
];

$arrDca['fields'] = array_merge($arrDca['fields'], $arrFields);#

---

Dabei fällt mir der erste Fehler auf: ich hab das ?> vergessen. :rolleyes:

Dennoch konnte ich nach einem leeren des Prod-Caches das Install-Tool ausführen, welches mir die gesamten Änderungen aufgeführt hat. Nicht alle konnten durchgeführt werden (vermutlich weil in manchen Spalten schon was drin war, ka.), aber insgesamt lief es durch. Dann kam der oben beschriebene Fehler, ich hab die tl_module.php wieder aus dem dca Verzeichnis gelöscht, Prod-Cache geleert, aber der Fehler ging nicht weg, obwohl das Install-Tool wieder die alten SQL Einträge hergestellt hat.

Jetzt hab ich das ganze Ding neu aufgesetzt, und hatte erstmal Probleme weil die tl_user nicht angelegt wurde, und damit das Install-Tool nicht starten konnte. Muss man denn nachdem man mit dem Web-Composer Contao 4.7 installiert hat, erstmal auf www.domain.tld/contao gehen, damit man danach das Install-Tool zum Datenbank-Update nutzen kann?! Macht ja aber auch keinen Sinn, da man die Zugangsdaten zu MySQL DB ja erst über das Install-Tool eingibt... echt komisch...

Zitat:

---

Zitat von Spooky

Contao bietet dafür aktuell keine Möglichkeit, nein.

---

Schade... kann man das irgendwo als "feature-request" einreichen? :) Oder läuft sowas unter ferner liefen, und wird deshalb eh nie Beachtung finden?

Zitat:

---

Zitat von JooNey

Schade... kann man das irgendwo als "feature-request" einreichen? :) Oder läuft sowas unter ferner liefen, und wird deshalb eh nie Beachtung finden?

---

Dazu gibt es irgendwo einen uralten Feature Request... ich finde ihn nur gerade nicht.

Zitat:

---

Zitat von Spooky

Dazu gibt es irgendwo einen uralten Feature Request... ich finde ihn nur gerade nicht.

---

Da ich mich grad mal wieder mit dem Thema beschäftige: Gibt es da mittlerweile schon Lösungsansätze? Verfolge die Entwicklung jetzt nicht so intensiv, dass mir das direkt auffallen würde. Angenommen dieser alte Feature Request ist noch offen, wo würde ich den denn finden können?

Alternativ: kann ich einfach ein neues Ticket öffnen?

Dabei stellt sich mir aber die Frage, was und wo?

Reduziert auf das eigentliche Problem ist es ja eigentlich ein MySQL Fehler, der auftritt, wenn man zu viele Spalten in einer Tabelle hat. Allerdings bezweifle ich, dass sich das ändert.

Bezogen auf Contao ist es so gesehen ein Fehler, da ich nur eine bestimmte Anzahl Module installieren kann, und danach das System nicht mehr nutzbar wird. Das hängt auch nicht mit bestimmten Modulen zusammen, sondern ist auf System-Ebene für alle gültig. (Ich hab es halt nur geschafft eine Modulkombination zu wählen, die diesen Fehler unglaublich schnell erzeugt. :rolleyes: )

Da ich aber anscheinend der Erste bin, dem sowas überhaupt passiert, ist die Frage, wie häufig das wirklich passiert, und wie relevant dann so ein Bug überhaupt wäre - und ob es nicht dann doch eher wieder ein "Feature" wird. (Obwohl es ja weiterhin das Contao dazu bringt nicht mehr zu funktionieren, wenn man mal die kritische Anzahl an Spalten in der tl_module angelegt hat.)

Ideen? Vorschläge? Ratschläge?

Viele Grüße

https://github.com/contao/core/issues/7313

Zitat:

---

Zitat von Spooky

https://github.com/contao/core/issues/7313

---

Danke für's Raussuchen. Kein Wunder, dass ich das nicht gefunden habe - im Core-Archiv habe ich nicht geschaut. Demnach wurde dieser Request aber nicht wirklich mit in V4 genommen, oder? Also doch n neues Ticket machen?

Da ich normalerweise nicht mit Ticket-Systemen arbeite, stelle ich lieber solche Fragen einmal mehr, als dass ich danach irgendwas mache, was vielleicht nicht gewünscht wäre.

VG.

Zitat:

---

Zitat von JooNey

Danke für's Raussuchen. Kein Wunder, dass ich das nicht gefunden habe - im Core-Archiv habe ich nicht geschaut. Demnach wurde dieser Request aber nicht wirklich mit in V4 genommen, oder? Also doch n neues Ticket machen?

---

Nein, alle offenen Feature Requests aus contao/core sind auch noch für neuere Contao Versionen relevant.

Das Feature wäre ein riesiger Umbau und sehr aufwändig umzusetzen, daher hat sich damit auch noch niemand damit befasst ;)

Ich hab das Problem jetzt auch bei Contao 4.9 - derzeit nur bei einer Testinstallation mit sehr vielen Erweiterungen, die gleichzeitig eingesetzt werden.
Da ich ja auch Erweiterungen entwickle, frage ich mich natürlich ganz besonders wie man das optimieren kann, damit die User weniger Probleme bei der Installation / Updates der Erweiterungen bekommen.
Ich habe es nun schon so gemacht, dass einige Felder Erweiterungsübergreifend gleich heißen (sowohl in tl_content als auch tl_module), aber das alles hat ja seine Grenzen.

Das Auslagern von Feldern wie hier geschildert, empfinde ich als sehr umständlich: https://github.com/contao/core/issues/7313

Contao bzw. die Fehlermeldung besagt ja man solle einige Felder in text umwandeln statt varchar(255).

Habe zu dem Thema jetzt einige Zeit gegoogelt und bin am überlegen, ob es nicht sinnvoll wäre viele Felder, die meist sowieso nicht befüllt sind (und nicht für das sortieren herangezogen werden) der Einfachheit halber einfach umstellt auf tinytext. Das ganze ist laut diverser Leute nicht so schnell wie varchar, aber wenn man die Daten lediglich bei einem bestimmten Modul abruft, sollte das ja alles nicht so das Problem sein. Zudem werden bei mysql bei Feldern vom Typ tinytext und text ja nur die Bytes genutzt, die auch wirklich befüllt sind. Varchar(255) speichert dagegen immer 255 Bytes, egal ob befüllt oder nicht, was ja totale Platzverwendung ist.
Anders sieht es sicherlich bei Feldern aus bei denen es sich um ein Pflichtfeld handelt und die immer befüllt und vielfach genutzt werden (Suchen, Sortieren etc.)

Ist da jetzt in meinen Überlegungen irgendwo ein Haken?

Du könntest ja auch einfach varchar(128) (oder andere Größen) nehmen, also zumindest bei Feldern, wo du dir sicher bist, dass die neue, kleinere Größe sicher immer ausreicht.

Das stimmt, für sich selbst kann man das ja immer relativ einfach entscheiden, aber für andere User kann man das nicht immer so klar sagen. Ich finds z.B. Quatsch, dass man bei nem Feld für den E-Mail-Betreff 255 Zeichen zulässt. Da reichen für mich persönlich sogar 64 aus.
Bei diesem Beispiel sieht man auch, dass es normalerweise nicht mal eines zusätzlichen Feldes in tl_module bedarf, wenn man nur 1 Modul auf der Seite hat wo das E-Mail-Betreff Feld von nöten ist. Das könnte man dann ja in tl_settings auslagern, aber man weiß ja nie auf welche Ideen die Leute kommen...

Klar, aber eine Extension kann halt auch nicht davon ausgehen, dass bspw. eine E-Mail Adresse immer nur kurz ist. Die Extension soll ja jeder benutzen können. Aber das gute an Contao ist ja, dass du, als Applikationsentwickler, dann trotzdem immer noch punktuell eingreifen und das DCA entsprechend abändern kannst.

Hatte bereits öfter bei Updates dieses Problem, wenn viele Erweiterungen installiert sind.
Wer keinen Zugriff auf die my.cnf hat, kann einfach in pma anstelle den Dump zu importieren den SQL-Befehl

Code:

---

SET SESSION innodb_strict_mode=0;

---

eingeben gefolgt von den Datenbank-Tabellen und deren Inhalte, die man hier aus dem Dump reinpastet.
Bei mir hats zumindest geholfen.

Habe gerade das ähnliche Problem und frage mich wie man nun am besten vorgehen sollte?

Macht es Sinn am Server was zu verändern um das Problem "hinauszuzögern" weil es ja zu einen Teil die Probleme der PluginEntwickler ist, wenn diese sich nicht an die Content Tabelle hängen würden. Siehe: https://github.com/contao/core/issues/7313
Weil eine "Verzögerung" durch die Felder verändern auf TEXT usw. kann früher oder später ja auch zu Problemen führen.

Ich habe gestern mal versucht wie im Issue: https://github.com/contao/contao/issues/1882 die innodb_page_size zu erhöhen.

Muss das heute nochmal probieren weil gestern kam es erst zu einen Fehler in meinen Docker System.

Habe es gerade nochmal in meiner Docker Umgebung nachgestellt und den Fehler von gestern konnte ich lösen.

Also um den #1118 Fehler zu lösen reichte es bei mir die Server Variable auf "innodb_page_size" zu erhöhen.

Standard ist diese bei MariaDB und MySQL auf 16384 gesetzt.

in der my.cnf

Code:

---

innodb_page_size=32768

---

reinschreiben und den Server neustarten.

Fehler von gestern:
Bei mir starte er nicht mehr in der Docker Umgebung. Habe die DB gelöscht und dann den Docker neu gestartet. Danach ein Backup wieder in die Contao DB eingespielt das ich davor gemacht habe.

Nun konnte ich im Installtoll alles ausführen und somit wieder alles gut.

Hoffe ich konnte andere auch damit helfen.