Connecting signal handlers in Django - Step-by-Step Execution

Concept Flow - Connecting signal handlers

Define signal handler function

↓

Import signal and handler

↓

Connect handler to signal

↓

Trigger signal event

↓

Signal calls handler

↓

Handler executes code

This flow shows how you define a function to handle a signal, connect it, then when the signal triggers, the handler runs.

Execution Sample

Django

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

@receiver(post_save, sender=MyModel)
def my_handler(sender, instance, **kwargs):
    print('Saved:', instance)

Defines a handler that prints a message whenever a MyModel instance is saved.

Execution Table

Step	Action	Signal	Handler Connected?	Handler Called?	Output
1	Import post_save and receiver	null	No	No
2	Define my_handler function	null	No	No
3	Connect my_handler to post_save for MyModel	post_save	Yes	No
4	Create and save MyModel instance	post_save	Yes	Yes	Saved: <MyModel instance>
5	Save another MyModel instance	post_save	Yes	Yes	Saved: <MyModel instance>
6	No more saves	post_save	Yes	No

💡 No more model saves, so signal not triggered and handler not called.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
handler_connected	false	true	true	true	true
handler_called	false	false	true	true	false
output			Saved: <MyModel instance>	Saved: <MyModel instance> Saved: <MyModel instance>	Saved: <MyModel instance> Saved: <MyModel instance>

Key Moments - 3 Insights

Why doesn't the handler run before connecting it to the signal?

Because in the execution_table at Step 3, the handler_connected changes from No to Yes. Before that, the signal has no handler to call.

What triggers the handler to run?

Saving a MyModel instance triggers the post_save signal, which calls the connected handler as shown in Steps 4 and 5.

Can the handler run if the signal is not connected?

No, the handler only runs if connected. The execution_table shows no output before connection at Step 3.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the handler first connected to the signal?

A Step 1

B Step 3

C Step 4

D Step 2

💡 Hint

Check the 'Handler Connected?' column in the execution_table.

At which step does the handler first get called and produce output?

A Step 4

B Step 3

C Step 2

D Step 1

💡 Hint

Look at the 'Handler Called?' and 'Output' columns in the execution_table.

If no MyModel instance is saved, what happens to the handler_called variable?

A It becomes true

B It toggles between true and false

C It stays false

D It causes an error

💡 Hint

Refer to variable_tracker for 'handler_called' values when no save occurs.

Concept Snapshot

Connecting signal handlers in Django:
1. Define a handler function.
2. Use @receiver decorator or connect() to link it to a signal.
3. When the signal triggers (e.g., model saved), handler runs.
4. Handlers receive sender, instance, and kwargs.
5. Connect before triggering signal to ensure handler runs.

Full Transcript

In Django, connecting signal handlers means writing a function that runs when something happens, like saving a model. First, you import the signal and the receiver decorator. Then, you define your handler function. Next, you connect the handler to the signal using @receiver or connect(). When the event happens, like saving a model instance, Django triggers the signal and calls your handler. The handler can then do things like print a message or update data. The execution table shows the steps: importing, defining, connecting, triggering, and handling. Variables track if the handler is connected and called. Beginners often wonder why the handler doesn't run before connecting; it only runs after connection and signal trigger. If no event happens, the handler never runs. This process helps keep code organized and reactive to events.

Practice

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