Есть ли какая-то причина, по которой я не должен делать вызовы базы данных от деструктора?

Question

Я хочу создать своего рода библиотеку datamapper, где вы бы сделали что-то вроде этого:

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

Теперь $users содержит 2 записи пользователя, но они еще не сохранены в базе данных. Чтобы быть эффективным, я бы хотел избавиться от них всех сразу. Я хотел бы иметь метод flush() для этого (не проблема), но я также хотел бы, чтобы это происходило неявно, когда ссылка на таблицу $users выпадает из области видимости. Есть ли причина, по которой я не должен делать это в деструкторе?

Answer 1

Я бы предложил, чтобы лучшим решением было бы вызвать ошибку в вашем деструкторе, если метод flush() явно не был вызван.

В этом случае, вероятно, лучше быть явным, и появление ошибки в деструкторе гарантирует, что вы определенно либо вызвали flush() (или «откат», либо как вы его называете). Вызывая ошибку, вы также получаете действительно личное уведомление о том, что что-то пошло не так, тогда как, если вы просто ничего не делаете, вы можете не заметить этого.

Answer 2

Нет никакой гарантии, что текущий порядок выключения интерпретатора PHP не изменится, и дескрипторы вашей базы данных могут быть уничтожены перед вызовом. (Вот почему это недокументировано между прочим ..)

Answer 3

Кто гарантирует, что ваша база данных доступна при вызове вашего деструктора?

Сборщики мусора обычно не гарантируют порядок выполнения деструкторов в графах объектов, поэтому вы даже не можете полагаться на какие-либо внешние ссылки. база данных еще хуже.

РЕДАКТИРОВАТЬ: ОК, php использует подсчет ссылок вместо поколения GC, но все еще плохая практика иметь побочные эффекты в деструкторах.* Что плохого в явном вызове flush?Возможно, пользователи вашей библиотеки просто хотят, чтобы некоторые изменения испарились.