pre_save and post_save signals in Django

Introduction

These signals let you run code automatically before or after saving data in the database. It helps keep your app organized and react to changes easily.

You want to check or change data before saving it to the database.

You need to update related data right after saving a record.

You want to send notifications or logs when data changes.

You want to enforce rules or validations automatically on save.

Syntax

Django

from django.db.models.signals import pre_save, post_save
from django.dispatch import receiver
from your_app.models import YourModel

@receiver(pre_save, sender=YourModel)
def before_save(sender, instance, **kwargs):
    # code to run before saving
    pass

@receiver(post_save, sender=YourModel)
def after_save(sender, instance, created, **kwargs):
    # code to run after saving
    # 'created' is True if new record was created
    pass

Use @receiver decorator to connect your function to the signal.

The instance is the actual model object being saved.

Examples

This sets a default title if none is given before saving a Book.

Django

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

@receiver(pre_save, sender=Book)
def set_default_title(sender, instance, **kwargs):
    if not instance.title:
        instance.title = 'Untitled Book'

This prints a message after a new Book is saved.

Django

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

@receiver(post_save, sender=Book)
def notify_new_book(sender, instance, created, **kwargs):
    if created:
        print(f'New book added: {instance.title}')

Sample Program

This example shows an Article model. Before saving, it sets a default title if none is given. After saving, it prints if the article was created or updated.

Django

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

class Article(models.Model):
    title = models.CharField(max_length=100, blank=True)
    content = models.TextField()

@receiver(pre_save, sender=Article)
def ensure_title(sender, instance, **kwargs):
    if not instance.title:
        instance.title = 'Default Title'

@receiver(post_save, sender=Article)
def announce_article(sender, instance, created, **kwargs):
    if created:
        print(f'Article created: {instance.title}')
    else:
        print(f'Article updated: {instance.title}')

Important Notes

Signals run automatically without changing your save() calls.

Be careful to avoid infinite loops if you save inside a signal handler.

Use signals to keep code clean and separate concerns.

Summary

pre_save runs before saving data to check or modify it.

post_save runs after saving to react to changes.

Use signals to automate tasks and keep your app organized.

Practice

1. What is the main purpose of the pre_save signal in Django?

easy

A. To run code after a model instance is deleted

B. To run code before a model instance is saved to the database

C. To run code after a model instance is saved to the database

D. To validate form data before submission

Solution

1. Step 1: Understand the timing of pre_save

   The pre_save signal triggers just before saving a model instance to the database.

2. Step 2: Compare with other signals

   post_save runs after saving, and deletion signals run on delete, so they don't match pre_save.

3. Final Answer:

   To run code before a model instance is saved to the database -> Option B

4. Quick Check:

   pre_save = before save [OK]

Hint: Remember: pre_save runs before saving data [OK]

Common Mistakes:

• Confusing pre_save with post_save
• Thinking pre_save runs after saving
• Mixing signals with form validation

2. Which of the following is the correct way to connect a post_save signal to a model named Book?

easy

A. post_save.connect(my_handler, sender=Book)

B. post_save.connect(Book, sender=my_handler)

C. Book.post_save.connect(my_handler)

D. connect.post_save(my_handler, Book)

Solution

1. Step 1: Recall the signal connection syntax

   The correct syntax is signal.connect(handler_function, sender=ModelClass).

2. Step 2: Match the syntax to options

   post_save.connect(my_handler, sender=Book) matches this pattern exactly, connecting my_handler to post_save for Book.

3. Final Answer:

   post_save.connect(my_handler, sender=Book) -> Option A

4. Quick Check:

   Signal.connect(handler, sender=Model) = correct [OK]

Hint: Signal.connect(handler, sender=Model) is the pattern [OK]

Common Mistakes:

• Swapping handler and sender arguments
• Trying to call connect on the model
• Using incorrect order of parameters

3. Given this code snippet, what will be printed when a new Author instance is saved?

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

@receiver(pre_save, sender=Author)
def before_save(sender, instance, **kwargs):
    print('Before saving:', instance.name)

@receiver(post_save, sender=Author)
def after_save(sender, instance, created, **kwargs):
    if created:
        print('Created:', instance.name)
    else:
        print('Updated:', instance.name)

# Assume instance.name = 'Alice' and this is a new save

medium

A. Updated: Alice

B. Created: Alice
Before saving: Alice

C. Before saving: Alice
Created: Alice

D. Before saving: Alice
Updated: Alice

Solution

1. Step 1: Understand signal order on save

   pre_save runs before saving, so it prints 'Before saving: Alice' first.

2. Step 2: Check post_save behavior for new instance

   post_save runs after saving; since created=True, it prints 'Created: Alice'.

3. Final Answer:

   Before saving: Alice Created: Alice -> Option C

4. Quick Check:

   pre_save then post_save with created=True = Before saving: Alice Created: Alice [OK]

Hint: pre_save prints first, post_save with created=True prints second [OK]

Common Mistakes:

• Assuming post_save runs before pre_save
• Ignoring the created flag in post_save
• Mixing update and create messages

4. You wrote this signal handler but it runs whenever ANY model is saved (not specifically for Product). What is the likely problem?

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

@receiver(post_save)
def product_saved(sender, instance, **kwargs):
    print('Product saved:', instance.name)

medium

A. Missing sender argument in @receiver decorator

B. Signal handler must be named post_save_handler

C. post_save signal cannot be used with Product model

D. print statement should be inside a try-except block

Solution

1. Step 1: Check the @receiver decorator usage

   The @receiver(post_save) decorator needs a sender=ModelClass argument to connect specifically to Product.

2. Step 2: Understand why handler runs for all

   Without sender=Product, the handler listens to post_save for all models, causing it to run whenever any model is saved.

3. Final Answer:

   Missing sender argument in @receiver decorator -> Option A

4. Quick Check:

   @receiver(post_save, sender=Model) required [OK]

Hint: Always specify sender=Model in @receiver for signals [OK]

Common Mistakes:

• Omitting sender argument in @receiver
• Assuming handler name matters
• Thinking post_save can't be used with certain models

5. You want to automatically set a model's slug field based on its title before saving, but only if the slug is empty. Which signal and approach is best?

hard

A. Use a form validation method to set slug before saving

B. Use post_save signal to update slug after saving the instance

C. Override the model's save() method and set slug after calling super().save()

D. Use pre_save signal to check if slug is empty and set it from title

Solution

1. Step 1: Identify when to set slug

   The slug should be set before saving to ensure it is stored correctly in the database.

2. Step 2: Choose the right signal

   pre_save runs before saving, allowing modification of fields like slug before the database write.

3. Step 3: Why not post_save or save override

   post_save runs after saving, so changing slug then requires another save. Overriding save() is possible but pre_save keeps logic separate and clean.

4. Final Answer:

   Use pre_save signal to check if slug is empty and set it from title -> Option D

5. Quick Check:

   Set fields before save with pre_save [OK]

Hint: Modify fields before saving with pre_save signal [OK]

Common Mistakes:

• Setting slug after saving causing extra saves
• Overriding save() but setting slug too late
• Using form validation which may not cover all saves