SoFunction
Updated on 2024-11-12

Django ForeignKey introduction to the use of foreign keys

This note introduces the Django system model's foreign key handling, ForeignKey and the corresponding processing methods.

This is a one-to-many field type that represents the association between two tables.

The table of contents for this note is below:

  • on_delete
  • related_name
  • related_query_name
  • Saving of foreign key fields

1、on_delete

Suppose there are two applications, app1 and app2.

A model under app1 is App1.

A model under app2 is App2.

# app1/
class App1():
    app2 = ("app2.App2", on_delete=)

# app2/
class App2():
    pass

When we set the ForeignKey, there is an on_delete parameter, which is mainly used to handle its own data when the data of the associated foreign key is deleted.

In our two model examples above, when a piece of data in App2 is deleted, the data in App1 that is associated with that piece of data is handled in the same way.

There are several main ways to handle this:

CASCADE
Associative deletion, when the data of App2 is deleted, the data associated with App1 is also deleted.

PROTECT
Protect processing, if App2 data is associated with App1, then the associated App2 data will not be deleted.

SET_NULL
If App2 data is deleted, the field in App1 associated with the deleted App2 data will be set to NULL.

DO_NOTHING
Without processing, the original data will not be manipulated in any way, which means that a piece of data in App2 will be deleted and the reference in App1 will still be there.

However, this is actually an unrecommended practice, because if you access this data in App1 and use the field app2, you will get an error.

2、related_name

ForeignKey has an attribute, related_name, that represents the name of the relationship from the related object to this object for display purposes only, but related_query_name defaults to the value related_name if the related_query_name field is not assigned a value.

Note: related_name has another use, that is, under the same class, if there are two fields that are foreign key fields of another model, then adding related_name is necessary to distinguish between the two fields.

Examples are shown below:

class Entry():
    blog_old = (Blog, related_name='old_entry')
    blog_new = (Blog, related_name='new_entry')

3、related_query_name

This field is primarily used for reverse filter searches. This field will default to the value of related_name if not assigned a separate value.

Regarding reverse filters, we can look at this functionality with the following two models:

class Blog():
    pass

class Entry():
    blog = (Blog)

Now that we have data for a Blog.

blog_1 = (id=1)

If we want to get the value of the field blog as blog_1 for all Entry tables, how do we handle it, in general:

entry_list = (blog=blog_1)

But since the blog field is a foreign key, we use a reverse filter to handle it:

entry_list = blog_1.entry_set.all()

The above is the usage of our reverse filter, which uses the lowercase name of the associated model + '_set', which is a fixed usage.

However, if we set the related_query_name field, the use of lowercase model name + '_set' can be deprecated, and we can use related_query_name directly, such as Entry as follows:

class Entry():
    blog = (Blog, related_name="entries")

At this point, we have not set the value of related_query_name, so the value of related_name will be used automatically, using the reverse filter as follows:

entry_list = blog_1.()

4. Saving of foreign key fields

First let's go over what a foreign key field looks like in the database and model.

In the model, taking Entry as an example, we can see that the key blog field, named 'blog', directly

But in the structure of the database, if we look at it, we can see that the field is blog_id.

When we get an Entry instance, for entry_obj.

entry_obj = (id=1)

When we output entry_obj.blog, what we return is an instance of Blog, which is an object that

Outputting entry_obj.blog_id, on the other hand, returns an int-type data.

So, how do we save the blog field for the Entry instance.
If we have a blog instance as blog_1, then it can be used directly:

entry_obj.blog = blod_1
entry_obj.save()

If we have a Blog with a primary key id of blog_id, then we can do this:

entry_obj.blog_id = blod_id
entry_obj.save()

This article on the use of Django foreign key ForeignKey introduction to the article is introduced to this, more related to Django foreign key ForeignKey content, please search for my previous posts or continue to browse the following related articles I hope you will support me in the future more!