Users Online

· Guests Online: 35

· Members Online: 0

· Total Members: 188
· Newest Member: meenachowdary055

Forum Threads

Newest Threads
No Threads created
Hottest Threads
No Threads created

Latest Articles

Articles Hierarchy

Django Tutorial

Django on_delete

Django on_delete

Introduction to Django on_delete

The following article provides an outline for Django on_delete. One of the major advantage of Django is its capability to make changes to the databases. The backend of Django framework-based applications can be very flexibly handled, all processes like database addition, deletion, or even updates can be very flexibly performed by means of Django models. The changes in the databases can also be integrated with the models in an easy and simple manner. The on delete is one among the parameters to have control of this flexibility that Django offers. This is among the parameters which are placed when a relationship is established in Django, this means the on delete function allows to flexibly operate on foreign keys.

So whenever foreign key-like concepts come into place these on delete arguments are expected to be declared as one among the parameters used in the foreign keys. These ondelete arguments decide whether a deletion must happen or what needs to be followed when the referenced object or parent value is deleted. This means when a referenced foreignkey value is deleted what needs to be the impact on the table which refers to the primary key is the context mentioned in Django delete argument. Options like this offer a great extent of flexibility to database-oriented operations.

Syntax of Django on_delete

Given below is the syntax of Django on_delete:

Field Name = models.ForeignKey(WASD, on_delete = OPERATION TYPE)

  • The left most value here represents the field which is going to be created in reference, this means the field which will be used to reference this operation on the background, so the field which is used to be the referential field or the field which will be acting to pull data from the parent field needs to be mentioned here. This will be the field which will be referenced further thought the framework. In database terms, the field which is given on the left end will act as the field inheriting the value of the foreignkey field.
  • Next the models.Foreignkey is the function that mentions that this operation is a foreign key creation operation. This function call is a mandatory item to use. It mentions that a foreign key is expected to be created further in this section. The syntax means that the from the models program the foreign key function is called and used. Next to these function names the arguments have to be placed. From a Django perspective this function call is a predefined function call. Lets discuss on the arguments used further.
  • After the models.Foreignkey function call the arguments of the function needs to be mentioned. This is where the on_delete method comes into play. First the WASD argument represents the foreign key which is expected to be inherited, next the on_delete function will be used. The on_delete function will be equaling it to the various options associated to it.

on_delete Options

The various options for the on_delete arguments are given below:

1. CASCADE

When the on_delete argument is set to cascade then deleting the referenced object will have substantial effect on the referred objects. This means when the referenced object is deleted from the database then all the entries of the object will also be deleted from the entire database. This is how the CASCADE option works in the background. So, there are some impacts on data integrity as far as the CASCADE options is concerned.

2. PROTECT

PROTECT is the direct opposite of cascade option, here if there is impact on the actual object then all instances of the data on the referenced object are not deleted. So, no deletion happens. This makes the data to be protected before delete processing on the referenced object.

3. RESTRICT

The RESTRICT is very similar to the PROTECT option, it does the same job just as like the deletion option. The only difference here is when deletion is targeted on the referenced object then the ON_DELETE will raise an error called the RestrictedError. But the RESTRICT will allow deletion to happen when the referencing object and the object which is referenced object is allotted with a reference to a different common object then the deletion is allowed to takes place.

4. SET_NULL

The option functions in the same way the name suggests, when a deletion happens to the referenced object then the value of the referencing object will be updated as NULL. So a NULL value will be placed for the referencing object. This is how the SET NULL will operate basically.

5. SET_DEFAULT

The option functions in the same way the name suggests, when a deletion happens to the referenced object then the value of the referencing object will be updated with a default value which it is allotted for, so all instances of the referencing object will be allotted with this default value. So a default value will be placed for the referencing object. This is how the SET DEFAULT will operate basically.

Create a Django on_delete Argument

Given below shows the creation of Django on_delete Argument:

Changes in Models.py file: The changes which are applied to the models.py file are depicted below; these changes will be reflected in the front end of the form used.

Here two different ondelete arguments are used, the RESTRICT and CASCADE options.

Example:

(models.py)

Code:

from django.db import models
from django.contrib.auth.models import User
# Model variables
# Create your models here.
class Bride(models.Model):
models.CharField(max_length=200,null=True)
…..
Example_Post_Graduation_college = models.CharField(max_length=400,null=True)
Example_Rasi = models.CharField(max_length=200,null=True)
Example_Nakshatra = models.ForeignKey(User, null=True, on_delete=models.RESTRICT)
Example_Creator = models.ForeignKey(User, null=True, on_delete=models.CASCADE)
def __str__(self):
return self.name

Output:

Django on_delete 1

Changes in Models.py file

Django on_delete 3

Explanation:

  • We can notice when a deletion is called on the creator for the record karthi, it does not imply to the record being placed on the user table because of the RESTRICT parameter used.

Conclusion

This article mentions on how flexibly options like on_delete can be used to flexibly delete a record and to control the impact of the deletion to the referenced records involved. This is among the key advantages of the database operations associated to the Django applications.

Comments

No Comments have been Posted.

Post Comment

Please Login to Post a Comment.

Ratings

Rating is available to Members only.

Please login or register to vote.

No Ratings have been Posted.
Render time: 0.82 seconds
10,841,857 unique visits