Home > Mobile >  Is there any other option for on_delete other than models.CASCADE for a ForeignKey in Django models?
Is there any other option for on_delete other than models.CASCADE for a ForeignKey in Django models?

Time:12-18

Why is the on_delete property of a ForeignKey in a Django model not default? That should be the case if there is no other option other than models.CASCADE. Is there any other option for the on_delete property?

CodePudding user response:

Yes, there are multiple builtin handlers for the on_delete=… parameter [Django-doc]. The documentation specifies:

  • CASCADE Cascade deletes. Django emulates the behavior of the SQL constraint ON DELETE CASCADE and also deletes the object containing the ForeignKey. (…)

  • PROTECT: Prevent deletion of the referenced object by raising ProtectedError, a subclass of django.db.IntegrityError.

  • RESTRICT: Prevent deletion of the referenced object by raising RestrictedError (a subclass of django.db.IntegrityError). Unlike PROTECT, deletion of the referenced object is allowed if it also references a different object that is being deleted in the same operation, but via a CASCADE relationship. (…)

  • SET_NULL: Set the ForeignKey null; this is only possible if null is True.

  • SET_DEFAULT: Set the ForeignKey to its default value; a default for the ForeignKey must be set.

  • SET(…): Set the ForeignKey to the value passed to SET(), or if a callable is passed in, the result of calling it. (…)

  • DO_NOTHING: Take no action. If your database backend enforces referential integrity, this will cause an IntegrityError unless you manually add an SQL ON DELETE constraint to the database field.

Furthermore you can also write your own handler for the on_delete=… parameter. For example in this article, I discuss implementing a handler that is to some extent the same as a SET(…) but the callable it uses accepts as parameter the object that should be updated.

In the "early days", and prior, you did not have to set an on_delete=… parameter: CASCADE was used as default value. But this makes it rather implicit what should happen in case the referenced object is removed, so later they made the parameter mandatory.

CodePudding user response:

Pulled these from djangos documentation here: https://docs.djangoproject.com/en/4.0/ref/models/fields/#foreignkey

They have code examples too.

The possible values for on_delete are found in django.db.models:

CASCADE Cascade deletes. Django emulates the behavior of the SQL constraint ON DELETE CASCADE and also deletes the object containing the ForeignKey.

Model.delete() isn’t called on related models, but the pre_delete and post_delete signals are sent for all deleted objects.

PROTECT Prevent deletion of the referenced object by raising ProtectedError, a subclass of django.db.IntegrityError.

RESTRICT Prevent deletion of the referenced object by raising RestrictedError (a subclass of django.db.IntegrityError). Unlike PROTECT, deletion of the referenced object is allowed if it also references a different object that is being deleted in the same operation, but via a CASCADE relationship.

SET_DEFAULT Set the ForeignKey to its default value; a default for the ForeignKey must be set.

SET() Set the ForeignKey to the value passed to SET(), or if a callable is passed in, the result of calling it. In most cases, passing a callable will be necessary to avoid executing queries at the time your models.py is imported:

DO_NOTHING Take no action. If your database backend enforces referential integrity, this will cause an IntegrityError unless you manually add an SQL ON DELETE constraint to the database field.

  • Related