Premier League Predictor: FastAPI & PostgreSQL — Chapter 2, Exercise 2
====================================================

TASK
Explain why Fixture's home_team and away_team relationships both need
an explicit foreign_keys=[...] argument, while SeasonTeam's team
relationship doesn't need one at all.

SOLUTION

SQLAlchemy normally figures out which foreign key column a relationship
should follow automatically, by looking for a single foreign key on the
table that points at the related class. That works fine for
SeasonTeam.team — there is exactly one foreign key column on
SeasonTeam that points at teams.id (team_id), so there's only one
possible answer and SQLAlchemy uses it without being told.

Fixture is genuinely different: it has TWO separate foreign key columns
that both point at the same table, teams.id — home_team_id and
away_team_id. When SQLAlchemy tries to work out what home_team should
join on, it finds two candidate columns instead of one, and has no way
to know on its own which one is meant for "home" and which is meant for
"away." That's a real ambiguity, not a missing feature — the same
ambiguity a person would have looking at two unlabeled arrows pointing
into the same table.

foreign_keys=[home_team_id] and foreign_keys=[away_team_id] resolve
that ambiguity explicitly, telling SQLAlchemy exactly which column each
relationship should use to look up the related Team row.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains SQLAlchemy's real default behavior (auto-detecting a single
foreign key), identifies exactly why that default breaks specifically
when two foreign keys point at the same table, and correctly states
what foreign_keys=[...] actually resolves — genuine ambiguity, not a
stylistic preference.