Nullable ForeignKeys и удаление ссылочного экземпляра модели - PullRequest
Новая
       20

Nullable ForeignKeys и удаление ссылочного экземпляра модели

7 голосов
/ 25 марта 2009

У меня есть ForeignKey, который может быть нулевым в моей модели для моделирования слабой связи между моделями. Это выглядит примерно так: 

class Message(models.Model):
  sender = models.ForeignKey(User, null=True, blank=True)
  sender_name = models.CharField(max_length=255)

При сохранении имя отправителя записывается в атрибут sender_name. Теперь я хочу иметь возможность удалить экземпляр пользователя, на который ссылается отправитель, и оставить сообщение на месте.

Из коробки этот код всегда приводит к удалению сообщений, как только я удаляю экземпляр пользователя. Поэтому я подумал, что обработчик сигналов будет хорошей идеей. 

def my_signal_handler(sender, instance, **kwargs):
  instance.message_set.clear()
pre_delete.connect(my_signal_handler, sender=User)

К сожалению, это ни в коем случае не решение. Каким-то образом Django сначала собирает то, что хочет удалить, а затем запускает обработчик pre_delete.

Есть идеи? Где узел в моем мозгу?

Ответы [ 2 ]

13 голосов
/ 25 марта 2009

Django действительно эмулирует поведение SQL ON DELETE CASCADE, и не существует готового документированного способа изменить это. Документы, в которых они упоминают об этом, находятся в конце этого раздела: Удаление объектов .

Вы правы, что Django собирает все связанные экземпляры модели, а затем вызывает обработчик предварительного удаления для каждого. Отправителем сигнала будет класс модели, который должен быть удален, в данном случае Message, а не User, что затрудняет обнаружение разницы между каскадным удалением, инициированным пользователем, и обычным удалением ... тем более, что сигнал на удаление класса User приходит последним, поскольку это последнее удаление: -)

Однако вы можете получить список объектов, которые Django предлагает удалить до вызова функции User.delete (). Каждый экземпляр модели имеет полуприватный метод с именем _collect_sub_objects(), который компилирует список экземпляров с указанием внешних ключей (он компилирует этот список без удаления экземпляров). Вы можете увидеть, как этот метод вызывается, взглянув на delete() в django.db.base.

Если бы это был один из ваших собственных объектов, я бы рекомендовал переопределить метод delete() в вашем экземпляре, чтобы запустить _collect_sub_objects (), а затем разбить ForeignKeys перед вызовом удаления суперкласса. Поскольку вы используете встроенный объект Django, который может оказаться слишком сложным для подкласса (хотя можно заменить собственный объект User на объект django), вам, возможно, придется полагаться на логику представления для запуска _collect_sub_objects и прерывания ФК перед удалением.

Вот быстрый пример: 

from django.db.models.query import CollectedObjects
u = User.objects.get(id=1)


instances_to_be_deleted = CollectedObjects()
u._collect_sub_objects(instances_to_be_deleted)

for k in instances_to_be_deleted.ordered_keys():
    inst_dict = instances_to_be_deleted.data[k]
    for i in inst_dict.values():
        i.sender = None  # You will need a more generic way for this
        i.save()

u.delete()
0 голосов
/ 14 апреля 2011

Только что обнаружив поведение ON DELETE CASCADE, я вижу, что в Django 1.3 они сделали поведение внешнего ключа настраиваемым .

...