Loading challenges
Nobody has started this yet — be first.
Business impact
A library tracker is only useful once someone has more than a handful of books in it -- and the first thing anyone reaches for at that point is "find the book called X." Right now that requires paging through the entire (unsearchable) list client-side, which gets slower and more annoying every time a book is added. This is the single most-requested kind of feature for any list-based app and its absence is the difference between "a tool I use" and "a tool I gave up on after 30 books."
Problem
BookFilter (books/filters.py) supports filtering the list endpoint by exact status and exact rating. There is no way to find a book by (partial) title or author -- a client has to fetch every page and filter client-side.
Current behavior
GET /api/books/?search=<term> is silently ignored; the endpoint returns every book instead of only the ones matching the search term.
Expected behavior
GET /api/books/?search=<term> returns only books whose title or author contains <term>, case-insensitively. An empty/no-match search returns an empty list, not every book. A missing search param behaves exactly as it does today (no filtering).
Steps to reproduce
curl -s "http://127.0.0.1:8000/api/books/?search=hail%20mary" | python -m json.tool
search query parameter is currently silently ignoredWhy this matters
REST_FRAMEWORK["DEFAULT_FILTER_BACKENDS"] in config/settings.py currently only wires up django_filters.rest_framework.DjangoFilterBackend (which drives BookFilter's exact-match fields). DRF ships a second, separate filter backend purpose-built for this -- rest_framework.filters.SearchFilter -- which reads a search_fields list off the view and does an icontains OR-search across all of them. Multiple filter backends can run on the same view at once; you don't have to choose between exact filtering and search.
Suggested approach
Look at books/views.py's BookViewSet and rest_framework.filters. You'll need the view to declare both its existing filterset_class and a search backend + search_fields, without changing the global DEFAULT_FILTER_BACKENDS setting (which would turn search on for every future viewset in this project, whether or not that's wanted).
Acceptance criteria
Verification
python manage.py test practicetickets.test_ticket03_search_filter -v 2
Hints (0/2)
Try it without hints first — the reading is the exercise.
Working on this ticket
Work on a branch named for the ticket — that's what you'll submit.
Branch off your fork
$git checkout -b feat/search-filterFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/search-filterSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign inhttp://127.0.0.1:8000/api/books/http://127.0.0.1:8000/admin/SECRET_KEYDEBUGALLOWED_HOSTSOr with Docker (migrations run automatically on container startup):
docker compose up --build
docker compose exec web python manage.py createsuperuser # optional, to use /admin/
Work the tickets in practicetickets/ (TICKET_01 through TICKET_07); each names one Django test:
python manage.py test practicetickets.test_ticket01_rating_boundary -v 2 # a single ticket
./practicetickets/run_tickets.sh # all 7, clean pass/fail summary
Tickets are independent and deliberately isolated from each other's bugs -- fix them in any order. python manage.py test books runs the project's own 4-test suite (separate from practicetickets/, which is never added to INSTALLED_APPS) and should report OK both before and after every ticket is fixed.
Level 2
Implement a feature
Extend the system within its own patterns.