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

TASK
Record a user, an expert, an AI, and two separately-named guest
predictions against a single real fixture, then call
GET /api/fixtures/{id}/predictions and confirm all five rows come
back with the correct source and guest_name values.

SOLUTION

Using a real fixture ID from Chapter 4 (42, in this example), five
separate POST requests to /api/fixtures/42/predictions:

  1. { "source": "user", "predicted_home_score": 2, "predicted_away_score": 1 }
  2. { "source": "expert", "predicted_home_score": 1, "predicted_away_score": 1 }
  3. { "source": "ai", "predicted_home_score": 2, "predicted_away_score": 0 }
  4. { "source": "guest", "guest_name": "Micah Richards", "predicted_home_score": 3, "predicted_away_score": 0 }
  5. { "source": "guest", "guest_name": "Jamie Carragher", "predicted_home_score": 1, "predicted_away_score": 0 }

Each of the five requests hits the "no existing row found" branch of
the route, since no two of them share the same (fixture_id, source)
pair (the two guest rows are additionally distinguished from each
other by guest_name) — so all five result in a genuine 201 INSERT,
not an UPDATE.

Calling GET /api/fixtures/42/predictions afterward returns exactly
five rows, matching the shape shown in the chapter's own real example
response:

  - source: "user", guest_name: null, 2-1
  - source: "expert", guest_name: null, 1-1
  - source: "guest", guest_name: "Micah Richards", 3-0
  - source: "guest", guest_name: "Jamie Carragher", 1-0
  - source: "ai", guest_name: null, 2-0

(Exact row order may vary slightly depending on insertion order, since
no ORDER BY clause is applied to this query.)

Confirming correctness means checking three things: that guest_name is
null for every non-guest row, that both guest rows carry their own
distinct real name rather than a shared or missing one, and that
there are exactly five rows total — not four, which would indicate the
two guest predictions were incorrectly treated as the same row by the
find-then-write logic.

WHY THIS WORKS AS AN ANSWER
----------------------------
It walks through all five real requests with concrete field values,
explains why each one takes the insert path rather than the update
path, and states exactly what a correct GET response should contain —
including the specific failure signature (four rows instead of five)
that would indicate the guest-name distinction wasn't actually
working.