Özel alanları wp_postmeta yerine gerçek, türlü tablolarda saklamak, bu blogda başka yazılarda anlatıldığı gibi size sıralama, dizinleme ve doğru türler kazandırır. Aynı zamanda wp_postmeta ile hiç yaşanmayan bir risk kategorisini de getirir: şema değişiklikleri. Bir sütunu yeniden adlandırmak veya türünü değiştirmek normal bir veritabanı işlemidir, ancak kendiliğinden güvenli bir işlem değildir; tabloları sizin adınıza yöneten bir eklentinin bunu ciddiye alması gerekir.
Bu yazı, Mass Custom Fields'ta bir alanı yeniden adlandırdığınızda, türünü değiştirdiğinizde veya kaldırdığınızda mekanik olarak tam olarak ne olduğunu ve alan grubu tanımlarınızla gerçek tablolarınız birbirinden ayrıştığında Table health'in ne yaptığını ele alır.
Her kaydın arkasındaki kurallar
Her alan bir sütundur; bu nedenle kayıtlı bir alan grubunu düzenlemek gerçek bir tabloyu değiştirir. Her kayıt için dört kural geçerlidir:
- Önce tablo, sonra tanım. Önce tablo değiştirilir. Alan grubu tanımı yalnızca bu işlem başarılı olursa saklanır; böylece başarısız bir kayıt ikisini uyumsuz bırakamaz.
- Ya hep ya hiç. Bir adım başarısız olursa (örneğin yeni bir benzersiz dizin yinelenen değerlerle karşılaştığında) o ana kadar yapılan adımlar geri alınır ve mesaj "Nothing was changed." ile biter.
- Kaldırma hiçbir zaman veri silmez. Kaldırılan bir alanın sütunu tabloda kalır.
- Riskli dönüştürmeler yedek tutar. Veri kaybına yol açabilecek bir dönüştürmeden önce eski değerler bir yedek sütuna kopyalanır.
Bir alanı yeniden adlandırmak veri kaybettirmez
Bir alanın anahtarını değiştirdiğinizde arka plandaki işlem, sil ve yeniden oluştur değil, bir sütun yeniden adlandırmasıdır. O sütundaki veriler olduğu yerde kalır; yalnızca sütunun adı değişir ve alanın dizinleri de onunla birlikte yeniden adlandırılır. Düzenleyici, kaydetmeden önce yeniden adlandırmanın RENAME COLUMN çalıştıracağı konusunda sizi uyarır. Bir sütunu yeniden adlandırmanın naif yolu (yenisini eklemek, değerleri kopyalamak, eskisini silmek) büyük tablolarda daha yavaştır ve daha çok yanlış gitme olasılığı taşır.
ALTER TABLE wp_wpmcf_fg_product
RENAME COLUMN release_date TO launch_date;Yeniden adlandırmadan sonra, eski anahtarı hâlâ kullanan şablonları, kısa kodları ve kodları güncelleyin.
Bir alanın türünü değiştirmek eski değeri korur
Bir alanın türünü değiştirmek yeniden adlandırmaktan daha risklidir; çünkü eski türdeki her değer yeni türe sorunsuz dönüşmez. Bir TEXT sütununu daha kısa bir VARCHAR sütununa kırpmak gerçek verileri kesebilir; serbest metni sayıya dönüştürmek sayısal olmayan değerleri NULL veya 0 yapar.
Riskli bir değişiklikte düzenleyici, üç seçenekli "This type change can lose data" iletişim kutusunu gösterir:
- Cancel; hiçbir şey değişmez.
- Convert with a backup. Eski değerler önce
{key}__bakadlı bir sütuna gider. Kaydettikten sonra dönüştürülen değerleri kontrol edin ve memnun kaldığınızda yedeği Table health altından silin. - Create a new field instead. Yeni türde ikinci bir alan eklenir ve eski sütuna dokunulmaz; bu, değerleri kendi kurallarınıza göre taşımak istediğiniz durumlara uygundur.
Text türünden Text area türüne geçmek gibi uyumlu bir değişiklik, sütunu yalnızca değiştirir ve değerleri korur.
Bir alanı kaldırmak verilerinizi silmez
Düzenleyiciden bir alanı kaldırmak, alan tanımını (alanı düzenlenebilir ve görünür kılan şeyi) kaldırır; ancak sütun ve değerleri tabloda artık sütun olarak kalır. Veri silmek ayrı ve açık bir eylemdir. Eklentiyi devre dışı bırakmak da hiçbir şeyi silmez; eklentiyi kaldırmak ise yalnızca Settings içindeki silme seçeneğini açtıysanız veri siler.
Artık bir sütunla aynı ada sahip yeni bir alan eklerseniz düzenleyici, yeni alanın kayıtlı değerleri kullanıp kullanmayacağını veya boş başlayıp başlamayacağını sorar; ikinci durumda eski değerleri bir yedek sütuna taşır.
Sapma (drift) ne demektir ve neden olur
Sapma, bir alan grubunun tanımının tablonun nasıl görünmesi gerektiğini söylemesi ile tablonun gerçekte nasıl göründüğü arasındaki her uyuşmazlıktır. Olağan nedenlerle ortaya çıkabilir: bir geliştirici SQL çalıştırmış, bir geçiş (migration) aracı bir sütunu silmiş veya bir yedek kısmen geri yüklenmiş olabilir.
Table health, bunu sonradan kafa karıştırıcı bir hata olarak keşfetmeye bırakmak yerine görünür kılmak için vardır. Kayıtlı her grup için bir sağlık rozeti ve boyut istatistikleri ile en fazla üç liste içeren bir Table differences paneli gösterir:
Liste | Anlamı | Eylemler |
|---|---|---|
Missing columns | Alan grubunda tanımlı ama tabloda bulunmayan | Add to DB |
Leftover columns | Tabloda olup tanımda bulunmayan, yedek sütunlar dahil | Import as fields, Remove from DB |
Changed outside the plugin | Veritabanındaki SQL türü tanımdan farklı | Sync to DB |
Hiç alan grubu olmayan tablolar, Field Groups listesinin en üstünde kayıtsız tablolar olarak görünür. Bunları bir grup olarak kaydedebilir veya silebilirsiniz.
Her panelin ayrıntıları için Table health sayfasına bakın.
Büyük tablolar arka planda değişir
Bazı şema işlemleri (örneğin çok sayıda mevcut satırı olan bir tabloya dizin eklemek) anlık değildir. Bir tabloda yaklaşık 100.000 veya daha fazla satır olduğunda değişiklik kuyruğa alınır ve WooCommerce'in de kullandığı aynı iş çalıştırıcısı olan Action Scheduler aracılığıyla arka planda çalışır. Düzenleyici bir Updating rozeti gösterir, site değişiklik tamamlanana kadar önceki tanımı kullanmaya devam eder ve bu sırada kaydedilen değerler korunur. Kuyruğa alınmış bir değişiklik iptal edilebilir; çalışmakta olan iptal edilemez.
Özet
Gerçek tabloları sizin adınıza yöneten bir eklenti, şema değişikliklerine özenli bir mühendisin elle uygulayacağı özenle yaklaşmalıdır: veriyi taşımayan yeniden adlandırmalar, geri dönüş yolunu koruyan tür değişiklikleri, siz söyleyene kadar sütuna dokunmayan kaldırmalar ve gerçeklikle tanım uyuşmadığında bunu size bildiren bir panel. Tüm kurallar bir alan grubunu güvenle değiştirme sayfasında anlatılır.
