У меня есть приложение Django 1.3, для которого я использую South 0.7.3 для БД. миграции. У меня проблема, когда правило on_delete = models.SET_NULL
, похоже, не срабатывает при удалении родительского объекта, что приводит к нарушению ограничений из базовой БД (которой является Postgres 8.4).
Соответствующие части определения сущности:
class AccessPeriod:
....
class Payment:
period = models.ForeignKey(
AccessPeriod, related_name = "payments", db_index = True,
null = True, on_delete = models.SET_NULL )
После некоторого раскопок я обнаружил, что South на самом деле не вставляет предложение ON DELETE
в SQL, который он генерирует для миграций, поэтому БД определенно не собираюсь выполнять аннулирование самих разорванных отношений:
http://south.aeracode.org/ticket/763
Затем я прочитал документацию Django для правил on_delete, в которых говорится (выделено мной):
Когда объект, на который ссылается ForeignKey, удаляется, Django по умолчанию имитирует поведение ограничения SQL ON DELETE CASCADE а также удаляет объект, содержащий ForeignKey.Это поведение можно переопределить, указав аргумент on_delete.
Часть "эмуляции" подсказала мне, что Django пытается реализовать само поведение on_delete и не полагается на базовую БД для автоматического выполнения этого как части транзакции, тем самым делая Ошибка юга не имеет значения.
Я прокрутил db / models / deletion.py
в исходном коде Django и основывался на реализации SET ()
/ SET_NULL ( )
и collect ()
определенно кажется, что Django должен делать это сам, однако, если я попытаюсь удалить AccessPeriod из администратора Django, я получаю нарушения ограничений в таблице Payments для Идентификатор, на который он ссылается, который теперь удален, т.е. не похоже, что Django вызывает SET_NULL ()
в отношении Payment.period
как часть вызова accessPeriod .delete ()
.
Я что-то делаю здесь не так, или неправильно понимаю, что Django sh может делать? Просто пытаюсь избежать ручного взлома БД, чтобы самому вставить правило ON DELETE, что кажется чрезвычайно хрупким и ужасным.