Per-view caching in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of a cached Django view after data changes?

Consider a Django view decorated with @cache_page(60). The view returns the current time. If the underlying data changes immediately after the first request, what will the second request within 60 seconds show?

Django

from django.views.decorators.cache import cache_page
from django.http import HttpResponse
import datetime

@cache_page(60)
def current_time(request):
    now = datetime.datetime.now()
    return HttpResponse(f"Current time: {now}")

A The second request returns an empty response due to caching.

B The second request raises a cache miss error because data changed.

C The second request shows the updated current time reflecting the data change.

D The second request shows the same time as the first request because the response is cached for 60 seconds.

💡 Hint

Think about what caching does to the response within the cache timeout period.

The @cache_page(60) decorator caches the entire response for 60 seconds. So, any request within that time returns the cached response, ignoring data changes.

📝 Syntax

intermediate

Which decorator syntax correctly applies per-view caching in Django?

Choose the correct way to apply a 5-minute cache to a Django view function.

A

@cache_page(5*60)
def my_view(request):
    return HttpResponse('Hello')

B

@cache_page
(300)
def my_view(request):
    return HttpResponse('Hello')

C

@cache_page(300, key_prefix='myprefix')
def my_view(request):
    return HttpResponse('Hello')

D

@cache_page(300)
def my_view(request):
    return HttpResponse('Hello')

💡 Hint

Remember the decorator syntax and optional parameters.

Option C correctly applies a 300-second cache with a key_prefix to avoid collisions. Option C is invalid syntax due to the line break. Options C and D are syntactically valid but lack the key_prefix.

🔧 Debug

advanced

Why does per-view caching not work for a Django view with POST requests?

A developer applies @cache_page(60) to a Django view that handles POST requests. The cache seems to never return cached responses. Why?

A Per-view caching only caches GET and HEAD requests by default, so POST requests are never cached.

B POST requests are cached but require a different decorator.

C The cache backend does not support POST request caching.

D The decorator must be applied after the view function, not before.

💡 Hint

Think about HTTP methods and caching behavior.

Django's per-view caching only caches GET and HEAD requests by default. POST requests are not cached because they usually change data and should not be cached.

🧠 Conceptual

advanced

How does the cache key affect per-view caching in Django?

What happens if two different views use @cache_page(60) without specifying a key_prefix and have the same URL pattern?

A Both views share the same cache key, causing cached responses to be mixed up.

B Django automatically generates unique keys per view, so no conflict occurs.

C The cache keys collide only if the views have the same function name.

D Caching is disabled if key_prefix is not specified.

💡 Hint

Consider how cache keys are generated and what happens if they overlap.

Without a unique key_prefix, cache keys can collide if URL patterns are the same, causing one view's cached response to be served for the other.

❓ state_output

expert

What is the number of cache entries after these requests with per-view caching?

Given two Django views, both decorated with @cache_page(120, key_prefix='view1') and @cache_page(120, key_prefix='view2') respectively, and the following sequence of requests:

1. Request to view1 with URL /page/1/
2. Request to view2 with URL /page/1/
3. Request to view1 with URL /page/2/
4. Request to view2 with URL /page/1/ again

How many unique cache entries exist after these requests?

A 1 unique cache entry

B 3 unique cache entries

C 2 unique cache entries

D 4 unique cache entries

💡 Hint

Think about how cache keys combine URL and key_prefix.

Each unique combination of view (key_prefix) and URL creates a unique cache entry. Requests 1 and 3 create two entries for view1 with different URLs. Requests 2 and 4 are for view2 with the same URL, so only one cache entry for view2.

Practice

1. What is the main purpose of using @cache_page(timeout) in Django views?

easy

A. To connect the view to the database

B. To save the view's output and speed up repeated visits

C. To validate user input before processing

D. To handle user authentication automatically

Solution

1. Step 1: Understand what caching does

   Caching stores the output of a view so it can be reused without recalculating.

2. Step 2: Recognize the role of @cache_page(timeout)

   This decorator saves the rendered page for the given timeout to speed up future requests.

3. Final Answer:

   To save the view's output and speed up repeated visits -> Option B

4. Quick Check:

   Per-view caching = save output for speed [OK]

Hint: Caching saves page output to speed up repeated visits [OK]

Common Mistakes:

• Thinking it validates input
• Confusing caching with authentication
• Assuming it connects to the database

2. Which of the following is the correct way to apply per-view caching with a 5-minute timeout in Django?

easy

A. @cache_page('300')
def my_view(request):
pass

B. @cache_page(5)
def my_view(request):
pass

C. @cache_page(timeout=5)
def my_view(request):
pass

D. @cache_page(300)
def my_view(request):
pass

Solution

1. Step 1: Understand the timeout parameter

   The timeout is in seconds, so 5 minutes = 300 seconds.

2. Step 2: Check correct syntax for @cache_page

   The decorator takes an integer timeout in seconds without quotes.

3. Final Answer:

   @cache_page(300)\ndef my_view(request):\n pass -> Option D

4. Quick Check:

   Timeout in seconds, no quotes = @cache_page(300) def my_view(request): pass [OK]

Hint: Timeout is seconds as integer, no quotes [OK]

Common Mistakes:

• Using string '300' instead of integer
• Passing timeout as minutes instead of seconds
• Using keyword argument timeout incorrectly

3. Given this Django view with per-view caching:

@cache_page(60)
def home(request):
    return HttpResponse(str(time.time()))

What will happen if you refresh the page multiple times within 60 seconds?

medium

A. The page shows the same timestamp for 60 seconds

B. The page shows a new timestamp on every refresh

C. The page raises an error because time.time() is not cached

D. The page shows timestamps increasing by 60 seconds

Solution

1. Step 1: Understand what @cache_page(60) does

   It caches the entire response for 60 seconds.

2. Step 2: Analyze the effect on time.time()

   Since the response is cached, the timestamp won't update until cache expires.

3. Final Answer:

   The page shows the same timestamp for 60 seconds -> Option A

4. Quick Check:

   Cache holds output unchanged for timeout [OK]

Hint: Cached view returns same output until timeout expires [OK]

Common Mistakes:

• Expecting timestamp to update every refresh
• Thinking caching only affects database queries
• Assuming cache raises errors with dynamic content

4. You wrote this Django view with caching:

from django.views.decorators.cache import cache_page

@cache_page('60')
def about(request):
    return HttpResponse('About page')

Why does this code cause an error?

medium

A. The timeout value is a string instead of an integer

B. The decorator is missing parentheses

C. The view function must be a class-based view

D. The import statement is incorrect

Solution

1. Step 1: Check the timeout argument type

   The timeout must be an integer number of seconds, not a string.

2. Step 2: Identify the error cause

   Passing '60' as a string causes a TypeError in the decorator.

3. Final Answer:

   The timeout value is a string instead of an integer -> Option A

4. Quick Check:

   Timeout must be int, not string [OK]

Hint: Timeout must be integer, not string [OK]

Common Mistakes:

• Using quotes around timeout number
• Forgetting parentheses on decorator
• Thinking function type matters here

5. You want to cache a Django view that shows user-specific data but still use per-view caching. Which approach correctly applies caching without showing wrong data to users?

hard

A. Cache the view globally and add user ID in the URL to separate cache keys

B. Use @cache_page(120) without changes; caching will separate users automatically

C. Use @cache_page(120) and add Vary: Cookie header to cache per user session

D. Do not use caching on user-specific views at all

Solution

1. Step 1: Understand caching user-specific data risks

   Global caching can show one user's data to others if not separated.

2. Step 2: Use Vary header to separate cache by user session

   Adding Vary: Cookie tells cache to store different versions per user session cookie.

3. Final Answer:

   Use @cache_page(120) and add Vary: Cookie header to cache per user session -> Option C

4. Quick Check:

   Vary header separates cache by user [OK]

Hint: Use Vary header to separate cache per user [OK]

Common Mistakes:

• Assuming caching separates users automatically
• Avoiding caching user views unnecessarily
• Adding user ID in URL without proper cache keys