alerion > Поэтому отработка их должна проходить железно.
Да, но для начала наверное кто-то должен послать сигнал? Походу с 1.3 пофиксили это дело.
Реализация сигналов сидит в django.dispatch/Signal
Я бегло посмотрел на исходники, честно скажу, мало чего понял, но, похоже, реализация основана на следующем:
1. метод connect подписывает модель на вызов callback функции (у меня post_delete).
2. Когда объект данного класса вызывает delete, в Signal сохраняется адрес объекта, проверяется открытая транзакция (с базой данных). Вызов callback функции откладывается до завершения транзакции. Объект не удаляется физически до завершения транзакции.
3. Когда транзакция завершается вызываются callback функции, передавая в её параметрах именованный параметр instance. Тут-то я беру этот instance, считая его своим объектом и удаляю свой файл с диска.
4. Объекты проделывают своё физическое удаление. Удаление из базы данных уже произошло во время транзакции.
5. Если транзакция завершается с ошибкой, база данных вернула всё взад, а объекты не удаляются, как будто ничего не происходило.
Таким образом слово signal не должно запутывать суть дела. Речь идёт не о посылке message между объектами, а о банальной callback функции. Таким образом, админка не посылает сигнал, всё реализовано на уровне классов и объектов самой django, работать должно всегда и везде.
Становится ясным, что данный механизм позволяет откатывать транзакцию с отменой физического удаления файла. В противном случае (как это было в старых версиях django) отмена транзакции в БД сопровождалась потерей файлов. Новый механизм позволяет избежать этого.
Если я прав, то данный механизм может глючить при многопоточном программировании. В исходниках я видел вызовы функций блокировки изменений списков, что при отсутствии ошибок в написании со стороны разработчиков, должно помочь.
Обновлено 22 Июнь 2012, 22:46 Holzer.
