pre_save and post_save signals in Django - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to import the Django signal used before saving a model instance.

Django

from django.db.models.signals import [1]

Drag options to blanks, or click blank then click option'

Apre_save

Bpost_save

Cm2m_changed

Drequest_finished

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing pre_save with post_save.

Importing unrelated signals like m2m_changed.

The pre_save signal is sent just before a model's save() method is called.

2fill in blank

medium

Complete the code to connect a function to the post_save signal for a model named Book.

Django

post_save.connect([1], sender=Book)

Drag options to blanks, or click blank then click option'

Asave_book

Bbook_saved_handler

Chandle_save

Dpost_save

Attempts:

3 left

💡 Hint

Common Mistakes

Using the signal name instead of a handler function.

Passing a string instead of a function reference.

The function connected to a signal should be a handler that processes the event, here named book_saved_handler.

3fill in blank

hard

Fix the error in the signal handler definition to accept the correct parameters.

Django

def [1](sender, instance, **kwargs):
    print(f"Saved: {instance}")

Drag options to blanks, or click blank then click option'

Apre_save_handler

Bpost_save

Cbook_saved_handler

Dhandle_save

Attempts:

3 left

💡 Hint

Common Mistakes

Using the signal name as the function name.

Mismatching handler names between connection and definition.

The handler function name should match the one connected to the signal, here book_saved_handler.

4fill in blank

hard

Fill both blanks to define a pre_save signal handler that modifies a model's field before saving.

Django

def [1](sender, instance, **kwargs):
    instance.title = instance.title.[2]()

Drag options to blanks, or click blank then click option'

Apre_save_handler

Bpost_save_handler

Cupper

Dlower

Attempts:

3 left

💡 Hint

Common Mistakes

Using post_save handler name for pre_save.

Using wrong string method like lower instead of upper.

The handler pre_save_handler modifies the title field to uppercase before saving.

5fill in blank

hard

Fill all three blanks to connect a pre_save handler and ensure it only runs for the Author model.

Django

from django.db.models.signals import [1]

[2].connect(pre_save_handler, sender=[3])

Drag options to blanks, or click blank then click option'

Apre_save

Bpost_save

CAuthor

DBook

Attempts:

3 left

💡 Hint

Common Mistakes

Importing or connecting the wrong signal.

Connecting the handler to the wrong model.

The pre_save signal is imported and used to connect pre_save_handler for the Author model only.

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