pre_save and post_save signals in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a pre_save signal modifies a model field?

Consider a Django model with a pre_save signal that changes a field value before saving. What will be the final saved value in the database?

Django

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

class Product(models.Model):
    name = models.CharField(max_length=100)
    price = models.DecimalField(max_digits=6, decimal_places=2)

@receiver(pre_save, sender=Product)
def update_price(sender, instance, **kwargs):
    if instance.price < 10:
        instance.price = 10.00

p = Product(name='Pen', price=5.00)
p.save()
print(Product.objects.get(name='Pen').price)

A 10.00

B 5.00

C 0.00

D Raises an error

💡 Hint

Think about when pre_save runs and what it can change.

The pre_save signal runs before the model instance is saved to the database. Modifying the instance's fields in pre_save changes what gets saved. Here, the price is set to 10.00 if it was less than 10 before saving.

❓ state_output

intermediate

What is printed by this post_save signal?

Given a post_save signal that prints a message after saving a model, what will be printed when a new instance is created?

Django

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

class UserProfile(models.Model):
    username = models.CharField(max_length=50)

@receiver(post_save, sender=UserProfile)
def notify_save(sender, instance, created, **kwargs):
    if created:
        print(f"Created user: {instance.username}")
    else:
        print(f"Updated user: {instance.username}")

u = UserProfile(username='alice')
u.save()

A Raises an error

B Created user: alice

C No output

D Updated user: alice

💡 Hint

Check the created flag in post_save.

The post_save signal receives a created boolean that is True when a new instance is created. The signal prints "Created user: alice" when saving a new UserProfile.

📝 Syntax

advanced

Which option correctly connects a pre_save signal to a model?

Select the code snippet that correctly registers a pre_save signal handler for a Django model named Order.

A

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

@receiver(pre_save, sender=Order)
def before_save(sender, instance, **kwargs):
    print('Saving order')

B

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

@receiver(post_save, sender=Order)
def before_save(sender, instance, **kwargs):
    print('Saving order')

C

from django.db.models.signals import pre_save

@pre_save.connect

def before_save(sender, instance):
    print('Saving order')

D

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

@receiver(pre_save)
def before_save(sender, instance, **kwargs):
    print('Saving order')

💡 Hint

Remember to specify the sender model in the @receiver decorator.

Option A correctly uses @receiver(pre_save, sender=Order) to connect the signal handler to the Order model's pre_save event.

Option A misuses @pre_save.connect without specifying sender and has wrong syntax.

Option A uses post_save instead of pre_save.

Option A misses the sender argument, so it listens to all models, which is usually incorrect.

🔧 Debug

advanced

Why does this post_save signal cause a recursion error?

Analyze the code below. Why does saving the instance inside the post_save signal cause a recursion error?

Django

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

class Profile(models.Model):
    bio = models.TextField(blank=True)

@receiver(post_save, sender=Profile)
def update_bio(sender, instance, **kwargs):
    if not instance.bio:
        instance.bio = 'Default bio'
        instance.save()

p = Profile()
p.save()

A Because the signal handler is missing the <code>created</code> argument.

B Because <code>post_save</code> signals cannot modify model instances.

C Because calling <code>instance.save()</code> inside <code>post_save</code> triggers <code>post_save</code> again, causing infinite recursion.

D Because <code>bio</code> field cannot be blank, causing a validation error.

💡 Hint

Think about what happens when you save inside a post_save signal.

Calling instance.save() inside a post_save signal triggers the signal again, causing infinite recursion and eventually a recursion error.

🧠 Conceptual

expert

Which statement best describes the difference between pre_save and post_save signals?

Choose the most accurate description of how pre_save and post_save signals behave in Django.

A <code>pre_save</code> only runs when creating new instances; <code>post_save</code> only runs when updating existing instances.

B <code>pre_save</code> runs after saving the instance; <code>post_save</code> runs before saving and can modify fields.

C <code>pre_save</code> and <code>post_save</code> both run after saving but differ in the order of execution.

D <code>pre_save</code> runs before the model instance is saved and can modify fields; <code>post_save</code> runs after saving and can access the saved instance but changes won't affect the current save.

💡 Hint

Consider when each signal is triggered relative to the database save operation.

pre_save is triggered before the model instance is saved to the database, allowing modifications to the instance before saving.

post_save runs after the instance is saved, so changes made in post_save do not affect the current save operation.

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