pre_save and post_save signals in Django - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the pre_save signal in Django?

The pre_save signal is sent just before a model's save() method is called. It allows you to run code or modify data before the object is saved to the database.

beginner

When is the post_save signal triggered in Django?

The post_save signal is triggered immediately after a model instance has been saved to the database. It is useful for actions that depend on the object being saved.

intermediate

How do you connect a function to the pre_save signal for a Django model?

You use the @receiver(pre_save, sender=YourModel) decorator or pre_save.connect(your_function, sender=YourModel) to link your function to the signal.

intermediate

What arguments does a signal handler for post_save receive?

A post_save handler receives sender, instance (the saved object), created (True if new object), update_fields, and kwargs.

advanced

Why might you use pre_save instead of overriding the save() method?

Using pre_save keeps your code separate from the model logic, making it easier to maintain and reuse. It also allows multiple functions to listen to the save event without changing the model.

Which signal is sent before a Django model instance is saved?

A pre_delete

B pre_save

C post_save

D post_delete

The pre_save signal is sent just before saving a model instance.

What does the created argument in a post_save signal handler indicate?

A If the instance was updated

B If the save was successful

C If the instance was deleted

D If the instance was newly created

The created argument is True if the instance was created, False if updated.

How can you connect a function to a Django signal?

A By overriding the model's <code>save()</code> method

B By importing the signal in views.py

C Using <code>@receiver</code> decorator or <code>signal.connect()</code>

D By calling the function manually

You connect signal handlers using the @receiver decorator or the connect() method.

Which signal would you use to perform an action after a model instance is saved?

A post_save

B pre_save

C pre_delete

D post_init

The post_save signal runs after the instance is saved.

What is a benefit of using Django signals like pre_save and post_save?

A They allow decoupled code to react to model events

B They automatically create admin pages

C They speed up database queries

D They replace the need for models

Signals let different parts of your app respond to events without tightly coupling code.

Explain how pre_save and post_save signals work in Django and when you might use each.

Think about what happens before and after saving a model.

Describe how to connect a function to a Django model's post_save signal and what arguments the function receives.

Focus on the connection method and handler parameters.

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