pre_save and post_save signals in Django - Deep Dive

Overview - pre_save and post_save signals

What is it?

In Django, pre_save and post_save signals are special notifications sent before and after a model instance is saved to the database. They allow developers to run custom code automatically at these moments without changing the save method itself. This helps keep code organized and lets different parts of an app react to data changes easily.

Why it matters

Without these signals, developers would have to manually call extra code every time they save data, which is error-prone and repetitive. Signals make it easy to add features like logging, validation, or updating related data automatically. This leads to cleaner, more maintainable code and fewer bugs.

Where it fits

Before learning signals, you should understand Django models and how saving data works. After mastering signals, you can explore other Django signals and advanced event-driven programming in Django apps.

Mental Model

Core Idea

pre_save and post_save signals are automatic alerts sent just before and just after saving data, letting your code react at the right moments without changing the save process itself.

Think of it like...

It's like a fire alarm system that rings before and after a fire drill, so people know when to prepare and when the drill is done, without interrupting the drill itself.

┌───────────────┐       pre_save signal       ┌───────────────┐
│ Model instance│ ──────────────────────────▶│ Signal handler│
│   save() call │                           └───────────────┘
│               │
│               │                           ┌───────────────┐
│               │       post_save signal      │ Signal handler│
│               │ ◀──────────────────────────│               │
└───────────────┘                           └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Django Model Saving

Concept: Learn how Django saves model instances to the database using the save() method.

When you create or update a Django model instance and call save(), Django writes the data to the database. This is the basic way to store or update data in your app.

Result

Data is stored or updated in the database when save() is called.

Understanding the save() method is key because signals hook into this process to add extra behavior.

2

Foundation

What Are Django Signals?

Concept: Signals are a way for parts of Django to send notifications when certain actions happen.

Django signals let different parts of your app listen for events like saving data or user login. When the event happens, Django sends a signal to all listeners, which can then run their own code.

Result

Your code can react automatically to events without changing the original code that triggered them.

Signals decouple event detection from event handling, making your code cleaner and more modular.

3

Intermediate

Using pre_save Signal

🤔Before reading on: do you think pre_save runs before or after the data is saved? Commit to your answer.

Concept: pre_save runs just before a model instance is saved, letting you modify or check data before it hits the database.

You connect a function to the pre_save signal for a model. This function receives the instance about to be saved and can change its fields or cancel saving by raising errors.

Result

Your function runs before the data is saved, allowing last-minute changes or validations.

Knowing pre_save runs before saving lets you safely adjust data or prevent bad data from being stored.

4

Intermediate

Using post_save Signal

🤔Before reading on: do you think post_save can tell if the instance was created or updated? Commit to your answer.

Concept: post_save runs right after a model instance is saved, letting you perform actions that depend on the data being stored.

You connect a function to post_save. It receives the saved instance and a flag showing if it was newly created or updated. You can use this to trigger tasks like sending emails or updating related models.

Result

Your function runs after saving, with full access to the saved data and context.

Understanding post_save timing helps you trigger side effects only after data is safely stored.

5

Intermediate

Connecting Signal Handlers Properly

Concept: Learn how to connect functions to signals using decorators or the connect() method.

You can use @receiver decorator or signal.connect() to link your function to pre_save or post_save. You specify the model to listen for and write your handler function with expected parameters.

Result

Your handler runs automatically when the signal fires for the specified model.

Proper connection ensures your code runs at the right time without manual calls.

6

Advanced

Avoiding Common Signal Pitfalls

🤔Before reading on: do you think signals run inside or outside the database transaction? Commit to your answer.

Concept: Signals run inside the database transaction, so errors in handlers can roll back saves, and handlers can cause unexpected side effects.

Because signals run during save(), if a handler raises an error, the whole save fails. Also, signals can cause infinite loops if they save the instance again inside the handler. You must design handlers carefully to avoid these issues.

Result

Understanding this prevents bugs like infinite loops or partial saves.

Knowing signals run inside transactions helps you write safe, side-effect-free handlers.

7

Expert

Signals vs Overriding save() Method

🤔Before reading on: do you think signals are better or worse than overriding save()? Commit to your answer.

Concept: Signals provide a decoupled way to add behavior around saving, while overriding save() embeds logic directly in the model.

Overriding save() is simpler but mixes concerns and can be harder to maintain. Signals let multiple parts of an app react independently. However, signals add complexity and can be harder to trace. Experts choose based on project needs.

Result

You learn when to use signals for modularity and when to override save() for simplicity.

Understanding tradeoffs helps you architect maintainable Django apps.

Under the Hood

Django's signal system uses a dispatcher that keeps track of registered handlers for each signal. When save() is called on a model, Django internally sends the pre_save signal before writing to the database and post_save after. Handlers are called synchronously in the same thread and transaction context, receiving the instance and other info as arguments.

Why designed this way?

Signals were designed to allow loose coupling between components, so apps can extend or react to core behaviors without modifying core code. This design supports reusable apps and cleaner separation of concerns. Alternatives like overriding save() tightly couple logic to models, reducing flexibility.

┌───────────────┐
│ save() called │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ pre_save sent │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Database write│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ post_save sent│
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does post_save run only when a new instance is created? Commit to yes or no.

Common Belief: post_save only runs when a new model instance is created.

Reality: post_save runs every time save() is called, both for new and updated instances. A flag tells you which case it is.

Why it matters: Assuming post_save runs only on creation can cause missed updates or incorrect logic.

Quick: Can pre_save cancel saving by returning False? Commit to yes or no.

Common Belief: Returning False from a pre_save handler stops the save operation.

Reality: pre_save handlers cannot cancel saving by returning values; to stop saving, they must raise exceptions.

Why it matters: Misunderstanding this leads to silent failures where invalid data is saved.

Quick: Do signals run asynchronously by default? Commit to yes or no.

Common Belief: Django signals run asynchronously in the background.

Reality: Signals run synchronously in the same thread and transaction as the save call.

Why it matters: Expecting asynchronous behavior can cause bugs and performance issues.

Quick: Can saving an instance inside a post_save handler cause infinite loops? Commit to yes or no.

Common Belief: It's safe to save the same instance inside a post_save handler without issues.

Reality: Saving inside post_save triggers signals again, causing infinite recursion unless carefully controlled.

Why it matters: Not controlling this leads to crashes and server overload.

Expert Zone

1

Signal handlers receive a 'using' parameter indicating the database alias, useful in multi-database setups.

2

Signals can be temporarily disconnected or muted to avoid unwanted side effects during bulk operations.

3

The order of signal handlers is not guaranteed, so handlers should not depend on each other's execution order.

When NOT to use

Avoid signals when the logic is simple and tightly related to the model; overriding save() or using model methods is clearer. For complex workflows, consider Django middleware or task queues instead of signals to improve traceability and performance.

Production Patterns

In production, signals are often used for audit logging, cache invalidation, sending notifications, and syncing related models. Experts use signals sparingly and document them well to avoid hidden side effects.

Connections

Event-driven programming

Signals are a form of event-driven programming within Django.

Understanding signals as events helps grasp how software can react dynamically to changes, a pattern common in many programming environments.

Observer design pattern

Django signals implement the observer pattern where observers listen to subjects' state changes.

Recognizing signals as observers clarifies their role in decoupling components and managing dependencies.

Publish-subscribe messaging systems

Signals are a lightweight, in-process version of pub-sub systems used in distributed computing.

Knowing this connection helps when scaling apps to use external message brokers for asynchronous processing.

Common Pitfalls

#1 Creating infinite loops by saving inside a post_save handler without control.

Wrong approach:

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=MyModel)
def update_related(sender, instance, **kwargs):
instance.save() # This triggers post_save again, causing infinite recursion

Correct approach:

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=MyModel)
def update_related(sender, instance, created, **kwargs):
if not created:
return
# safe to save or update related models here without recursion

Root cause:

Not checking if the instance is newly created or updated causes recursive saves.

#2 Assuming pre_save can stop saving by returning False.

Wrong approach:

from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def validate(sender, instance, **kwargs):
if not instance.is_valid():
return False # This does NOT stop saving

Correct approach:

from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def validate(sender, instance, **kwargs):
if not instance.is_valid():
raise ValueError('Invalid data') # Raises error to stop saving

Root cause:

Misunderstanding how signal handlers control flow; only exceptions interrupt saving.

#3 Connecting signal handlers multiple times causing duplicate executions.

Wrong approach:

def connect_signals():
post_save.connect(my_handler, sender=MyModel)

connect_signals()
connect_signals() # Called twice, handler runs twice per save

Correct approach:

from django.dispatch import receiver

@receiver(post_save, sender=MyModel)
def my_handler(sender, instance, **kwargs):
pass # Decorator ensures single connection

Root cause:

Manually connecting signals multiple times without safeguards causes repeated calls.

Key Takeaways

pre_save and post_save signals let your code react automatically before and after saving data in Django models.

pre_save runs before data is saved, allowing you to modify or validate data, while post_save runs after, letting you trigger side effects safely.

Signals run synchronously inside the save transaction, so errors in handlers affect saving and handlers must avoid infinite loops.

Using signals helps keep your code modular and clean but requires careful design to avoid hidden bugs and performance issues.

Knowing when to use signals versus overriding save() or other methods is key to building maintainable Django applications.