Exercise 2: Why No Composite Index Is Required — Possible Solution
====================================================================

WHY THIS QUERY DOESN'T NEED ONE
------------------------------
This chapter's query runs on a real relational database via Django's ORM, which has no equivalent of Firestore's requirement that certain multi-field filter combinations need a pre-declared composite index before the query is even allowed to execute. A query combining an equality filter (status="active") and a range filter (expiry_date__lte=threshold) on two different fields simply runs as ordinary SQL - there's no separate index-declaration step required just to make the query legal to run at all.

THE TRADEOFF THAT STILL EXISTS WITHOUT AN INDEX
------------------------------
Without an actual database index covering these fields, the query can still run - it just does so less efficiently, via something closer to a full table scan, as the table of items grows larger. This is the same performance-only tradeoff SQL databases generally accept: an unindexed query is a performance cost, not a functional refusal to execute, unlike Firestore's own behavior of refusing to run the equivalent query at all until an index exists.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that Django's ORM has no functional index requirement analogous to Firestore's composite-index rule, and correctly identifies that the real tradeoff without an index is purely a performance cost (a slower query as data grows) rather than the query being blocked from running entirely.