Bir sorgu yazarken tablo ve kolon adlarının editörde görünmesi hoşuma gidiyor. Yanlış bir kolon adı yazdıysam bunu uygulamayı çalıştırmadan fark edebilmek istiyorum. TypeScript tarafında sorgu araçlarından beklediğim ilk şey bu.
Ama tiplerin doğru olması, sorgunun veritabanında da doğru çalışacağı anlamına gelmiyor. Şema değişip migration uygulanmadıysa kodun derlenmesi pek bir şey çözmüyor. Tip kontrolü ile veritabanının gerçek durumunu ayrı kontrol etmek gerekiyor.
Sorguya bakabilmek
Bir sorgu yavaşladığında hangi SQL'in çalıştığını görmek istiyorum. Dönen satır sayısı, join'ler ve indeksler hâlâ işin içinde. Kullandığım araç bunları görmemi zorlaştırıyorsa, yazarken kazandığım kolaylığı hata ayıklarken kaybediyorum.
Bu yüzden araç seçerken yalnızca ne kadar az kod yazdırdığına bakmıyorum. Üretilen sorguya ulaşmak, migration'ı incelemek ve gerektiğinde doğrudan SQL yazabilmek benim için önemli.
Servisin nerede çalıştığı da bağlantıyı etkiliyor. Runtime'ın desteklediği sürücüyü ve bağlantı yöntemini proje özelinde kontrol etmek gerekiyor. Tek bir karşılaştırma tablosuyla bütün veritabanları ve çalışma ortamları için karar vermek bana pek güvenilir gelmiyor.
TypeScript'in kontrol ettiği şey
Basit bir örnek için sorgu sonucunu şöyle tanımladığımı düşünelim:
type PlaceRow = {
id: string;
name: string;
};
function placeLabel(place: PlaceRow) {
return place.name.toUpperCase();
}
Bu fonksiyonda place.title yazarsam TypeScript alanın bulunmadığını söyleyebilir. Ama dışarıdan gelen bir nesneyi as PlaceRow diye işaretlemek, içindeki alanları kontrol etmez. Bu yalnızca derleyiciye verdiğim bir bilgi. Verinin gerçekten doğru olduğundan emin olmak için runtime'da doğrulama veya güvenilir bir veri sınırı gerekir. TypeScript dokümanı bu ayrımı açıkça anlatıyor.
Veritabanında da benzer bir ayrım var. Kod name alanını beklerken bağlı olduğum ortamda o kolon yoksa sorgu çalışmaz. Migration, veritabanının şemasını değiştiren SQL adımıdır; TypeScript tipini değiştirmek bu adımı uygulamaz.
SQL'i görmek neden işime yarıyor?
Örneğin bir yerin son on kaydını istiyorum:
SELECT id, name
FROM places
ORDER BY created_at DESC
LIMIT 10;
Bunu bir ORM ile yazsam da sonunda veritabanına böyle bir sorgu gider. Sonuç beklediğim gibi değilse önce filtreyi, sıralamayı ve hangi ortamın veritabanına bağlandığımı kontrol ederim. Yavaşsa yürütme planına bakmak gerekir; sadece sorgu kodunun kısa görünmesinden performansını çıkaramam.
Tip güvenliği bu kontrollerin yanına ekleniyor. Editörde hata yakalamak güzel, ama bağlı olduğum şema ve çalışan SQL hâlâ kontrol etmem gereken şeyler.