Каковы последствия применения ограничений внешних ключей django на уровне базы данных?
Мы хотим добавить в существующее приложение django реализацию внешних ключей на уровне базы данных и нам интересно, каких побочных эффектов нам следует ожидать от этого.
Некоторые пояснения более подробно:
У нас есть приложение Django, основанное на бэкенде postgresql. Довольно много данных, внешних ключей, таблиц и т.д.
Раньше мы работали исключительно на базе django, поэтому даже не замечали, что на самом деле django не реализует внешние ключи на уровне базы данных, а скорее эмулирует их в стеке python.
Теперь мы пытаемся интегрировать другой проект, который отправляет SQL-запросы, которые мы хотели бы применить к базе данных django. Таким образом, мы получаем утверждения типа DELETE FROM foo WHERE id=bar. Эти утверждения могут не сработать из-за внешних ключей, которые реализованы как ON DELETE RESTRICT (а может NO ACTION, сейчас не помню) изначально в django.
Для решения нашей проблемы мы решили изменить внешние ключи в postgres, чтобы подражать поведению django (при каскадном удалении или основном set null). При этом ничего не меняя в коде django. Один комментарий от 'dirkgroten', найденный в Django does not honor ON DELETE CASCADE, кажется, предполагает, что это не сломает основное приложение, но прежде чем мы запустим его в производство и обнаружим какой-нибудь неприятный побочный эффект, мы задали вопрос здесь, чтобы узнать, может быть, кто-то уже тестировал это или увидел что-то, чего мы не поняли.
Я представляю, что некоторые сигналы django не будут срабатывать, но кроме нашего кода, который может справиться с этим, я не знаю, полагаются ли некоторые действия ядра django на сигналы для работы.
Мы прекрасно понимаем, что любое изменение внешних ключей django models должно быть идентично отражено в FK postgres после миграции, но здесь вопрос не в этом.