Exercise 1: Why ModelForm Avoids a Duplication FastAPI Accepts — Possible Solution
====================================================================

WHAT ModelForm ACTUALLY DOES
------------------------------
ItemForm's Meta class points directly at the Item model from Chapter 2 and lists which of its fields to include. Django generates the form's own fields and validation rules - max_length constraints, blank/required behavior, choices restrictions - by reading that same Item model definition directly, rather than requiring a second, separately-written description of those same fields anywhere else.

WHY FASTAPI'S APPROACH DOES DUPLICATE THIS
------------------------------
FastAPI has no equivalent mechanism connecting its request-validation layer directly to a SQLAlchemy model. Instead, a separate Pydantic schema class has to be written by hand, restating the same fields, types, and constraints the SQLAlchemy model already defines - two separate class definitions describing overlapping information about the same underlying data, kept in sync manually by the developer.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that ModelForm reads Chapter 2's Item model directly as its single source of truth for both fields and validation, and correctly contrasts this with FastAPI's separate Pydantic schema, which restates the same information a second time rather than deriving it from the existing model.