Ben yıkıcı veritabanı çağrıları yapmamalısınız herhangi bir neden var mı?

3 Cevap php

Ben böyle bir şey yapacağını datamapper kütüphane, bir tür oluşturmak istiyorsanız:

$users = Users::getTable();
$users->add($newUser1);
$users->add($newUser2);

Şimdi $users 2 kullanıcı kayıtlarını içerir, ancak henüz veritabanına kalıcı olmaz. Verimli olması için, ben de hepsini birden temizlemek istiyorum. Ben bu (bir sorun değil) yapmak için flush() yöntemi istiyorum, ama $users tablo referans kapsamı dışında düştüğünde örtülü gerçekleşmesi için ben de isterim. Ben yıkıcı bunu yapmamalıyız herhangi bir neden var mı?

3 Cevap

Ben flush() yöntemi açıkça denilen edilmemiş ise daha iyi bir çözüm yıkıcı raise an error olacaktır öneririz.

Bu durumda, açık ve yıkıcı bir hata yükseltme olmak için muhtemelen daha iyi kesinlikle ya flush() (ya da "geri alma" ya da ne olursa olsun onu aramak) aradım sağlar. Eğer sadece bir şey yaparsanız, o zaman fark edemeyebilirsiniz oysa bir hata yükselterek, aynı zamanda, bir şeylerin yanlış gittiğini gerçekten in-your-face bildirim almak.

Orada geçerli PHP yorumlayıcı kapatma sırası değişmez dair hiçbir garanti olursa olsun, ve veritabanı kolları çağrıldığını önce tahrip olabilir. (Btw belgelenmemiş yüzden ..)

Kim yıkıcı denir zaman mevcut veritabanı garanti?

Çöp toplayıcılar genellikle nesne grafikler yıkıcılar için yürütme sırasını garanti etmiyoruz, bu yüzden bile herhangi bir dış referanslar dayanmaz olabilir. A database daha da kötüdür.

EDIT: OK, php uses ref counting instead of a generational GC, but it's still bad practice to have side-effects in destructors.

Ne açıkça floş çağırarak bu kadar kötü? Belki kütüphane kullanıcıları sadece bazı değişiklikler buharlaşmasına izin vermek istiyorum.

etiketler