Premier League Predictor: Astro — Chapter 3, Exercise 1
====================================================

TASK
Explain why the POST /api/seasons route clears is_current on every
other season with a plain UPDATE before inserting the new one, and
what would go wrong if that step were skipped.

SOLUTION

The app relies elsewhere (the gameweek/season selector in Chapter 10,
and any route that needs to know "which season is active right now")
on there being exactly one season with is_current = 1 at any given
time. Nothing about the seasons table's own schema enforces that rule
by itself — is_current is just a plain 0/1 column on every row, with
no constraint saying "only one row may hold a 1."

If a new season were inserted with is_current = 1 without first
clearing every other season's own flag, the table could end up with
two (or more) rows all marked current at once. Any code that expects
exactly one current season — for example, a query doing
"SELECT * FROM seasons WHERE is_current = 1" and assuming it gets back
a single row — would then either return multiple ambiguous results or
silently pick an arbitrary one, depending on how that code is written.

The plain UPDATE seasons SET is_current = 0 run before the INSERT
guarantees the invariant holds by construction: by the time the new
season is inserted with is_current = 1, every other row is already
guaranteed to hold 0, so exactly one row can ever be current
immediately afterward.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the real invariant the app depends on (exactly one
current season), explains precisely how the schema fails to enforce
it on its own, and describes a concrete, realistic failure mode
(multiple "current" rows breaking any code that assumes there's only
one) if the clearing step were skipped.