Is there any reason I shouldn't do database calls from the destructor?

Question

I want to create a sort of datamapper library, where you'd do something like this:

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

Now $users contains 2 user records, but they aren't yet persisted to the database. To be efficient, I'd like to flush them all at once. I would like to have a flush() method to do this (not an issue), but I'd also like for it to happen implicitly when the $users table reference falls out of scope. Is there any reason I shouldn't do this in the destructor?

Answer 1

Who guarantees your database is available when your destructor is called?

Garbage collectors usually do not guarantee the order of execution for destructors in object graphs, so you may not even rely on any external references. A database is even worse.

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

What's so bad about calling flush explicitly? Maybe users of your library simply want to let some changes evaporate.

Answer 2

I would suggest a better solution would be to raise an error in your destructor if the flush() method has not been explicitly called.

In this case, it's probably better to be explicit and raising an error in the destructor ensures that you've definitely either called flush() (or "rollback" or whatever you call it). By raising an error, you also get a really in-your-face notification that something went wrong, whereas if you just do nothing, then you might not notice it.

Answer 3

There is no warranty whatsoever that the current PHP interpreter shutdown order will not change, and your database handles might be destroyed before being called. (That's why it is undocumented btw..)