How do I create a Django model with ForeignKeys which does not cascade deletes to its children?

Question

One of my models which has ForeignKey's is actually a MySQL view on other tables. The problem I'm running into is that when I delete data from these tables, Django, as described in the "deleting objects" documentation...

When Django deletes an object, it emulates the behavior of the SQL constraint ON DELETE CASCADE -- in other words, any objects which had foreign keys pointing at the object to be deleted will be deleted along with it.

...tries to remove rows from my view, which of course it can't, and so throws the error:

mysql_exceptions.OperationalError '>=(1395, "Can not delete from join view 'my_db.my_mysql_view'"'

Is there any way to specify a ForeignKey constraint on a model which will provide me with all the Django wizardry, but will not cascade deletes onto it? Or, is there a way to ask MySQL to ignore the commands to delete a row from my view instead of raising an error?

Answer 1

Well, looking at delete method

def delete(self):
    assert self._get_pk_val() is not None, "%s object can't be deleted because its %s attribute is set to None." % (self._meta.object_name, self._meta.pk.attname)

    # Find all the objects than need to be deleted.
    seen_objs = CollectedObjects()
    self._collect_sub_objects(seen_objs)

    # Actually delete the objects.
    delete_objects(seen_objs)

I'd say overriding delete should be enough...untested code would be

def delete(self):
    assert self._get_pk_val() is not None, "%s object can't be deleted because its %s attribute is set to None." % (self._meta.object_name, self._meta.pk.attname)

    # Find all the objects than need to be deleted.
    seen_objs = CollectedObjects()
    seen_objs.add(model=self.__class__, pk=self.pk, obj=self, parent_model=None)

    # Actually delete the objects.
    delete_objects(seen_objs)

Answer 2

Django's ForeignKey manager has a method called clear() that removes all objects from the related object set. Calling that first, then deleting your object should work. The dependent objects will have their foreign keys set to None (if allowed in your model).

A short description here: http://docs.djangoproject.com/en/dev/topics/db/queries/#following-relationships-backward

Answer 3

One way is to call clear method before deleting, documentation here which basically "clears" the relationship. One problem thought: it's not auto by itself. You can choose: call it every time you don't want cascade, or use the pre_delete signal to send clear before each delete, of course it'll give you problems when you DO want delete - cascade.

Or you can contribute to the django community and add the keyword argument to delete, maybe it'll be in django 1.3?:D

Answer 4

Harold's answer pointed me in the right direction. This is a sketch on the way I implemented it (on a french legacy database, hence the slightly odd naming convention):

class Factures(models.Model):
    idFacture = models.IntegerField(primary_key=True)
    idLettrage = models.ForeignKey('Lettrage', db_column='idLettrage', null=True, blank=True)

class Paiements(models.Model):
    idPaiement = models.IntegerField(primary_key=True)
    idLettrage = models.ForeignKey('Lettrage', db_column='idLettrage', null=True, blank=True)

class Lettrage(models.Model):
    idLettrage = models.IntegerField(primary_key=True)

    def delete(self):
        """Dettaches factures and paiements from current lettre before deleting"""
        self.factures_set.clear()
        self.paiements_set.clear()
        super(Lettrage, self).delete()

Answer 5

FYI - a feature request for this exists in the django source repository at http://code.djangoproject.com/ticket/7539. It looks like this topic is getting some attention. Hopefully it will be included in future Django releases.

The ticket includes patches to Django's core to implement an "on_delete" optional parameter to models.ForeignKey(...) that lets you specify what happens when the pointed to Model is deleted, including turning off the default ON DELETE CASCADE behavior.

Answer 6

Re: http://code.djangoproject.com/ticket/7539

No attention as of Django 1.2.1, June 2010. I guess we need to "watch that space".