Bird
Raised Fist0
Djangoframework~5 mins

Connecting signal handlers in Django

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction

Connecting signal handlers lets your Django app react automatically when certain actions happen, like saving a record. It helps keep your code organized and responsive.

You want to send a welcome email right after a new user signs up.
You need to update related data whenever a model instance is saved.
You want to log changes automatically when a database record is deleted.
You want to trigger background tasks after a model is created or updated.
Syntax
Django
from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=YourModel)
def your_handler(sender, instance, created, **kwargs):
    if created:
        # code to run after a new instance is saved
        pass

The @receiver decorator connects your function to a signal.

The sender argument specifies which model triggers the signal.

Examples
This example sends a welcome email when a new User is created.
Django
from django.db.models.signals import post_save
from django.dispatch import receiver
from myapp.models import User

@receiver(post_save, sender=User)
def send_welcome_email(sender, instance, created, **kwargs):
    if created:
        print(f"Welcome email sent to {instance.email}")
This example logs a message before an Article is deleted.
Django
from django.db.models.signals import pre_delete
from django.dispatch import receiver
from myapp.models import Article

@receiver(pre_delete, sender=Article)
def log_article_deletion(sender, instance, **kwargs):
    print(f"Article titled '{instance.title}' is about to be deleted.")
Sample Program

This code defines a Product model and connects a signal handler to post_save. When a product is saved, if its stock is less than 5, it prints a warning message.

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

class Product(models.Model):
    name = models.CharField(max_length=100)
    stock = models.IntegerField(default=0)

@receiver(post_save, sender=Product)
def notify_low_stock(sender, instance, **kwargs):
    if instance.stock < 5:
        print(f"Warning: Low stock for product '{instance.name}'")

# Simulate saving products
p1 = Product(name='Pen', stock=10)
p1.save()
p2 = Product(name='Notebook', stock=3)
p2.save()
OutputSuccess
Important Notes

Signals run synchronously by default, so avoid long tasks inside handlers.

Always specify the sender to avoid handling signals from unrelated models.

Summary

Signals let your app react automatically to model events.

Use @receiver to connect handlers to signals.

Check the created flag to run code only on new records.

Practice

(1/5)
1. What is the main purpose of connecting signal handlers in Django?
easy
A. To style HTML templates dynamically
B. To manually call functions from views
C. To create new database tables
D. To automatically run code when certain model events happen

Solution

  1. Step 1: Understand signal handlers

    Signal handlers let Django apps respond automatically to events like saving or deleting a model.
  2. Step 2: Identify the purpose

    Connecting signal handlers means running code automatically when these events happen, without manual calls.
  3. Final Answer:

    To automatically run code when certain model events happen -> Option D
  4. Quick Check:

    Signal handlers = automatic event response [OK]
Hint: Signals run code automatically on model events [OK]
Common Mistakes:
  • Thinking signals create database tables
  • Confusing signals with manual function calls
  • Assuming signals style templates
2. Which of the following is the correct way to connect a signal handler using the decorator in Django?
easy
A. @receiver(post_save, sender=MyModel) def my_handler(sender, instance, **kwargs): pass
B. @signal(post_save, sender=MyModel) def my_handler(sender, instance): pass
C. @connect(post_save, sender=MyModel) def my_handler(instance): pass
D. @listen(post_save, sender=MyModel) def my_handler(sender): pass

Solution

  1. Step 1: Recall the correct decorator

    Django uses @receiver to connect signal handlers, not @signal, @connect, or @listen.
  2. Step 2: Check function parameters

    The handler must accept sender, instance, and optionally **kwargs. @receiver(post_save, sender=MyModel) def my_handler(sender, instance, **kwargs): pass matches this.
  3. Final Answer:

    @receiver(post_save, sender=MyModel) def my_handler(sender, instance, **kwargs): pass -> Option A
  4. Quick Check:

    Use @receiver with correct params [OK]
Hint: Use @receiver decorator with sender and signal [OK]
Common Mistakes:
  • Using wrong decorator names
  • Missing sender argument
  • Incorrect handler parameters
3. Given this code snippet, what will be printed when a new Book instance is created?
from django.db.models.signals import post_save
from django.dispatch import receiver

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

book = Book.objects.create(title='Django Basics')
medium
A. New book added:
B. New book added: Django Basics
C. No output
D. Error: missing argument

Solution

  1. Step 1: Understand the signal and handler

    The post_save signal triggers after saving a model. The handler checks if created is True, meaning a new record.
  2. Step 2: Analyze the code execution

    Creating a new Book instance sets created=True, so the print statement runs with the title.
  3. Final Answer:

    New book added: Django Basics -> Option B
  4. Quick Check:

    post_save with created=True prints title [OK]
Hint: Check 'created' flag to print on new records only [OK]
Common Mistakes:
  • Ignoring the 'created' flag
  • Assuming no output on create
  • Confusing signal arguments
4. Identify the error in this signal handler connection code:
from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save)
def handler(sender, instance, **kwargs):
    print('Saved!')
medium
A. Missing sender argument in @receiver decorator
B. Handler function missing 'created' parameter
C. post_save signal is not imported correctly
D. Handler function should not have **kwargs

Solution

  1. Step 1: Check the @receiver decorator usage

    The @receiver decorator requires the signal and optionally the sender. Omitting sender means the handler listens to all senders, which is allowed but often unintended.
  2. Step 2: Identify the likely error

    Since the question asks for an error, the missing sender argument is the problem if the handler is meant for a specific model.
  3. Final Answer:

    Missing sender argument in @receiver decorator -> Option A
  4. Quick Check:

    Specify sender to target model signals [OK]
Hint: Always specify sender to avoid catching all signals [OK]
Common Mistakes:
  • Not specifying sender when needed
  • Assuming 'created' param is always required
  • Misunderstanding **kwargs usage
5. You want to run a function only when a new UserProfile is created, not when updated. Which is the best way to connect the signal handler?
hard
A. Use @receiver(post_save) without sender and ignore created flag
B. Use @receiver(pre_save, sender=UserProfile) and always run the function
C. Use @receiver(post_save, sender=UserProfile) and check if created is True inside the handler
D. Use @receiver(post_delete, sender=UserProfile) to detect creation

Solution

  1. Step 1: Identify the correct signal for creation

    post_save runs after saving, and the created flag tells if it's a new record.
  2. Step 2: Choose the best method

    Using @receiver(post_save, sender=UserProfile) and checking created inside the handler ensures the function runs only on creation.
  3. Final Answer:

    Use @receiver(post_save, sender=UserProfile) and check if created is True inside the handler -> Option C
  4. Quick Check:

    post_save + created=True = run on new only [OK]
Hint: Check 'created' flag in post_save for new records only [OK]
Common Mistakes:
  • Using pre_save which runs before saving
  • Using post_delete which runs on deletion
  • Ignoring the created flag and running always