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

TASK
Explain why create_season clears is_current on every other season with a
bulk update before inserting the new one, and what would go wrong if
that step were skipped.

SOLUTION

"Current season" is meant to be a single fact about the whole app, not
something each Season row decides independently — the schema has no
built-in way to guarantee that on its own, since is_current is just a
plain boolean column on every row. Nothing stops two, three, or every
season in the table from being marked True at the same time unless the
application actively prevents it.

The bulk update() call does exactly that: before the new season is even
inserted, every existing row's is_current flag is set to False in the
same request. Only after that does the new season get added with
whatever is_current value was actually requested. That ordering
guarantees at most one row can end up True once the whole operation
finishes.

If that step were skipped, creating a new "current" season while an old
one was still marked current would leave TWO rows with is_current =
True at once. Any part of the app that assumes there's exactly one
current season — for example, a route that fetches "the" current season
by filtering on is_current = True and expects a single result — would
either get an ambiguous result (two matching rows) or silently pick
whichever one happens to come back first, which is not a real, reliable
answer to "which season is active right now."

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies that nothing in the schema itself prevents
multiple current seasons, explains what the bulk update actually
guarantees and why the ordering (clear, then insert) matters, and
describes a concrete real consequence of skipping it rather than a
vague "it would break."