How an ORM Works
Understand the pattern under every ORM — Hibernate, SQLAlchemy, GORM, EF Core — instead of memorizing one library's API: the object-relational mismatch, mapping objects to tables, the identity map and unit of work, change tracking and dirty checking, lazy loading and the N+1 trap, how a query builder becomes SQL, and when not to use an ORM at all. Language-agnostic, concept-first.
- What an ORM Is (the Mismatch) An ORM translates between your code's objects and a database's rows because the two don't line up — the object-relational impedance mismatch. Meet that mismatch and the four jobs every ORM does.
- Mapping Objects to Tables The first job every ORM does: a set of correspondence rules turning classes into tables, fields into columns, references into foreign keys, and collections into one-to-many — by convention plus configuration.
- The Identity Map & Unit of Work Inside the ORM session: how it keeps one in-memory object per row (the identity map) and batches every change into a single all-or-nothing commit (the unit of work).
- Change Tracking & Dirty Checking How an ORM knows what to UPDATE without you calling save — snapshots and dirty checking, proxies and notifications, and the detached-object trap that bites every web app.
- Lazy Loading & the N+1 Trap When related data loads — lazy (on access) vs eager (up front) — and the N+1 query explosion every ORM can cause in an innocent loop, plus the fix and how to choose per query.
- Building the Query (to SQL) The ORM's fourth job: you describe a query in objects — a method chain, criteria, LINQ, or QuerySet — and it compiles that to parameterized SQL, runs nothing until you enumerate, and stays injection-safe by default.
- When Not to Use an ORM The honest limits of ORMs — where they shine (CRUD over object graphs) versus where to reach for raw SQL or a micro-ORM, the alternatives spectrum, and where to go next.