Y at-il une raison pour laquelle je ne devrais pas faire des appels de base de données à partir du destructeur?

Question

Je veux créer une sorte de DataMapper bibliothèque, où vous feriez quelque chose comme ceci:

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

maintenant $users contient 2 enregistrements d'utilisateurs, mais ils ne sont pas encore à la base de données persistaient. Pour être efficace, je voudrais les débusquer tous en même temps. Je voudrais avoir une méthode flush() pour ce faire (pas un problème), mais j'aimerais aussi que cela se produise implicitement lorsque la référence de la table $users tombe hors de la portée. Y a-t-il une raison pour laquelle je ne devrais pas faire ça dans le destructeur?

Answer 1

Je suggérerais une meilleure solution serait de soulever une erreur dans votre destructeur si la méthode flush() n'a pas été explicitement appelée.

Dans ce cas, il est probablement préférable d'être explicite et d'élever une erreur dans le destructeur assure que vous avez certainement appelé flush() (ou "rollback" ou peu importe comment vous l'appelez). En soulevant une erreur, vous obtenez également une notification en face-à-face que quelque chose s'est mal passé, alors que si vous ne faites rien, vous ne le remarquerez peut-être pas.

Answer 2

Qui garantit que votre base de données est disponible lorsque votre destructeur est appelé?

Les garbage collectors ne garantissent généralement pas l'ordre d'exécution des destructeurs dans les graphiques d'objets, vous ne pouvez donc même pas vous fier à des références externes. Une base de données est encore pire. OK, php utilise le comptage de référence au lieu d'un GC générationnel, mais il est toujours mauvais d'avoir des effets secondaires dans les destructeurs.

Qu'y a-t-il de mal à appeler explicitement flush? Peut-être que les utilisateurs de votre bibliothèque veulent simplement laisser certains changements s'évaporer.

Answer 3

Il n'existe aucune garantie que l'ordre d'arrêt de l'interpréteur PHP actuel ne changera pas, et vos handles de base de données pourraient être détruits avant d'être appelés. (C'est pourquoi il est non documenté btw ..)