ForeignKey และ on_delete

Real data connects: a book has an author, an order has a customer. A ForeignKey is how one model points to another.

A ForeignKey models a one-to-many link. One author can have many books, but each book belongs to exactly one author.

Add a field of type ForeignKey and point it at the related model. Django stores the link as an id column behind the scenes.

In the database, an author ForeignKey becomes an author_id column holding the other row's primary key. That number is the actual link.

Every ForeignKey needs on_delete. It tells Django what to do with this row when the row it points to is deleted.

CASCADE deletes this row too when its parent goes. Remove an author and all their books vanish with them.

Use PROTECT to refuse the delete while related rows exist. Django raises an error instead of removing the parent.

SET_NULL keeps the row but clears the link, setting the column to NULL. It needs null=True on the field to work.

SET_DEFAULT swaps in the field's default, while DO_NOTHING leaves the database to decide. Reach for these only in special cases.

From a book instance you read the linked author straight through the field. Django fetches that row for you on demand.

Span the relationship in queries with the double underscore. Reach into the related model's fields directly from filter.

You delete an author but want their books to stay, just unlinked. Which on_delete value fits?

Nice work! A ForeignKey models one-to-many links, and on_delete decides each row's fate when its parent is removed. 🔗