Почему моя модель не имеет & ldquo; on_delete = models.CASCADE, & rdquo; генерировать каскадное ограничение внешнего ключа?

Question

Почему моя модель не имеет & ldquo; on_delete = models.CASCADE, & rdquo; генерировать каскадное ограничение внешнего ключа?

Для Swift 3 для меня работало следующее, и синтаксис Swift 2 не работал:

// menu is a dictionary in this example

var menu = ["main course": 10.99, "dessert": 2.99, "salad": 5.99]

let sortedDict = menu.sorted(by: <)

// without "by:" it does not work in Swift 3

4

python-3.x django python postgresql cascading-deletes

задан Ahtisham 22 January 2019 в 18:43

1 ответ

Другие вопросы по тегам:

python-3.x django python postgresql cascading-deletes

Похожие вопросы:

score 0 · Answer 1

Как описано в документации django ForeignKey , django просто эмулирует это поведение, а не откладывает его в базу данных.

Django эмулирует поведение ограничения SQL ON DELETE CASCADE, а также удаляет объект, содержащий ForeignKey.

Итак, чтобы ответить на ваш вопрос: это ожидаемое поведение и все равно будет работать так же, как вы ожидаете, что оно будет работать на уровне базы данных.
Как еще можно заставить мой файл models.py вывести ограничение каскадного удаления внешнего ключа?

Вы не можете, поскольку в настоящее время django не поддерживает эту функцию. Однако есть билет, обсуждающий его добавление: https://code.djangoproject.com/ticket/21961

Изменить для дальнейшего разъяснения о том, как применить это в базе данных- level

Хотя я настоятельно рекомендую просто позволить django справиться с этим для вас, могут быть причины не делать этого.

Чтобы отказаться от операций по созданию или удалению таблицы базы данных, вы можете установить Options.managed в False в классе Meta из ArticleStat. Это, однако, также означает, что вы теперь несете ответственность за ручную миграцию, например, написать оператор CREATE TABLE для определения таблицы, включающей ограничение внешнего ключа (которое теперь у вас есть полный контроль). Еще одно соображение, которое следует принять во внимание, заключается в том, что вы должны указать django больше ничего не делать при удалении объекта Article, на который есть ссылка (так как ваша база данных теперь отвечает за это). Это можно обеспечить, установив on_delete в models.DO_NOTHING .

Теперь ваши ArticleStat будут выглядеть следующим образом:
class ArticleStat(models.Model):
    article = models.ForeignKey(Article, on_delete=models.DO_NOTHING)

    class Meta:
        managed = False
Комментарий о сигналах побудил меня вернуться к этому и перечислить некоторые подводные камни, которые нужно рассмотреть.

Отказ означает также отказ от сигналов Django. В частности, pre_delete и post_delete больше не будут запускаться для каскадных объектов.

Как упомянуто в описании билетов , смешивание базы данных и django-каскадирование не будут хорошо сочетаться.

Если модель A ссылается на модель B с использованием CASCADE_DB, а модель B ссылается на модель C с использованием обычного CASCADE, удаление A не будет каскадно полностью вплоть до C.

При этом я не смог найти какое-либо определенное доказательство того, почему django ведет себя так, как в настоящее время. [Тысяча сто тридцать одна]