Premier League Predictor: Django & MySQL — Chapter 2, Exercise 2
====================================================

TASK
Explain what would actually happen if a team were recorded as playing
itself on a MySQL 8.0.15 database with this exact CheckConstraint in
place, and why that differs from what would happen on MySQL 8.0.16 or
later.

SOLUTION

On MySQL 8.0.15 (or any earlier version): the CREATE TABLE statement
Django's migration generates would still include the real CHECK clause
syntax — MySQL would accept and store it as part of the table
definition without complaint. But per MySQL's own documented behavior
for every version before 8.0.16, that CHECK clause is parsed and then
silently ignored by every storage engine at actual insert/update time.
That means attempting to save a Fixture with home_team and away_team
both set to the same team would succeed with no error at all — the row
would be inserted into the database exactly as if the constraint didn't
exist, even though it appears to be present in the table's own schema.
The constraint provides zero real protection on this version, despite
looking fully configured.

On MySQL 8.0.16 or later: the identical CHECK clause is genuinely
enforced. Attempting to save a Fixture with home_team equal to
away_team would be rejected by MySQL itself at the database level with
a real constraint-violation error, the same real protection this
course's own FastAPI/PostgreSQL sibling gets from its own equivalent
CheckConstraint — PostgreSQL has enforced CHECK constraints properly
for a very long time, so that course never had this particular gap to
worry about at all.

The real, practical takeaway: the exact same Django model code and the
exact same generated SQL behave completely differently depending on
which MySQL version is actually running underneath — a genuine,
version-dependent trap that isn't visible just from reading the model
definition or even the generated migration file.

WHY THIS WORKS AS AN ANSWER
----------------------------
It describes the concrete, different real outcomes on both sides of
the 8.0.16 boundary (silent success on the old version vs. a real
rejected save on the new one), and explicitly contrasts this with the
FastAPI/PostgreSQL sibling course, which never has this specific
version-dependent gap at all.