Migrate schedule types to Strawberry Django

[patrick91]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
pycon	Ready	Preview	Aug 14, 2026 7:59am

[codecov]

Codecov Report

❌ Patch coverage is 98.23009% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.74%. Comparing base (df05a0a) to head (c2f201e).

Additional details and impacted files

@@                         Coverage Diff                         @@
##           codex/strawberry-django-keynote    #4728      +/-   ##
===================================================================
+ Coverage                            92.66%   92.74%   +0.07%     
===================================================================
  Files                                  360      360              
  Lines                                11170    11210      +40     
  Branches                               895      898       +3     
===================================================================
+ Hits                                 10351    10397      +46     
+ Misses                                 696      690       -6     
  Partials                               123      123              

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[claude]

Migrates the schedule/conference GraphQL types from plain strawberry.type to strawberry_django.type, delegating prefetch/select_related/annotation optimization to the Strawberry Django optimizer instead of manually building prefetch querysets in days()/talk().

No blocking issues found. One thing worth confirming with the author:

• backend/api/schedule/types/schedule_item.py speakers(): when info.context._participants_data is empty, it now builds the participants cache by querying all schedule items for the whole conference (submission/keynote/additional speakers via subqueries) rather than just the speakers of the single item being resolved (as the old fallback did). This is fine — and clearly intentional, given the new test_schedule_capacity_query_is_constant test — for the "fetch full schedule" path where it avoids N+1 across many items, but it means a query for a single talk (e.g. conference.talk(slug)) now pulls participant rows for the entire conference instead of just that talk's speakers. test_fetch_schedule_talk still asserts only 4 queries, so round-trip count is unaffected, but result-set size for that single-talk path grows with conference size. Worth a quick sanity check that this trade-off is intended.