Exercise 1: Why This Advantage Isn't FastAPI-Specific — Possible Solution
====================================================================

THE THREE COURSES THAT SHARE IT
------------------------------
Food Tracker (Django), Food Tracker (React + Express), and Food Tracker (FastAPI) all get native, case-insensitive substring search essentially for free - Django's icontains lookup, Express's raw SQLite LIKE, and this course's SQLAlchemy ilike() all rely on the same underlying capability that real relational databases and their query layers already provide.

THE ONE COURSE THAT DOESN'T
------------------------------
Food Tracker (React + Firebase) is the exception - Firestore, being a document database rather than a relational one, has no native case-insensitive substring search capability at all. That course had to maintain a separate, duplicated nameLower field specifically to work around that missing capability.

WHY THIS ISN'T A FASTAPI-SPECIFIC ADVANTAGE
------------------------------
Since three genuinely different frameworks (Django, Express, and FastAPI), all sitting on top of a real SQL database, share this same capability expressed in their own idiom, the advantage clearly belongs to the underlying relational-database technology itself, not to any one of those three frameworks specifically. FastAPI didn't invent ilike() - SQLAlchemy provides it as a standard way to express a SQL feature that's been available in relational databases all along.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly names all three SQL-backed courses as sharing the advantage, correctly names Firebase as the one exception and why, and correctly explains why the shared advantage across three different frameworks points to it being a relational-database capability rather than something specific to any single framework.