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.