Django Fundamentals: The ORM, Migrations, and Shipping a Real App

Part 1 of 18 · ~1 min

Overview

Here's the incident this whole reference is secretly about. Priya builds ToolShed — a website for a street's worth of neighbors to list tools they own and borrow each other's — in a weekend, as a favor to her block association. It works. People list drills and ladders and pressure washers, other people request them, everyone's happy. Then, four months in, the "Browse Tools" page — the page literally every visitor hits first — starts taking three seconds to load. Nothing crashed. Nothing logged an error. The page just got slow, gradually, in a way nobody could point to a specific change for.

That's not really a story about one bug. It's a story about the fact that Django's easiest path — the one that gets a working site out the door in a weekend — quietly sets several traps that only spring once the data stops being small. This reference builds ToolShed from that first working weekend version through to the one that survives real neighborhood-scale traffic: a schema that gets safer as it grows instead of more dangerous, a browse page that stays fast with six hundred tools instead of six, and a delete button that can't accidentally erase who's holding your ladder.

Every chapter below is a fix to that same running app, taken roughly in the order Priya actually ran into them. Reading straight through tells the whole incident; landing on a single chapter from a search result works too, since each one starts by saying which version of ToolShed it's about to change.