Inheritance & Polymorphic Queries

## What the mapper has to decide A row is only values. Nothing in it says the record is a card payment rather than a bank transfer; the class is a fact the **mapping metadata** adds on top of the data. So for any mapped type that has subclasses, every read gains a step before hydration: **choose the concrete class**, then fill an instance of that class. The choice is made once, at hydration, and everything afterwards follows it — type tests, virtual dispatch, narrowing, even how the object serializes. Two mechanisms cover nearly all of what data-access layers do here, and the table layout decides which one is available. Some layers additionally let application code register its own resolver, but that is the exception rather than the norm. ## Mechanism one: a type marker stored with the row An extra column holds a value naming the concrete class — a short code, a small integer, or the class name itself. At startup the layer builds a registry from the mapping metadata, and each read looks the row's marker up in that registry. - Deciding costs **nothing extra**: the marker rides along in a SELECT the layer was issuing anyway. - It works whether the subtype's own columns sit in the same wide table or in a joined child table. In the joined case the marker also tells the layer which child table to expect, so it can skip the rest. - Narrowing a query to a few subtypes becomes an ordinary predicate on the marker column, which an index can serve: `... WHERE kind IN ('CARD', 'VOUCHER')`. - Marker values are **data**. They outlive the code that wrote them, so a marker derived from a class name turns a rename or a package move into a data migration. - A marker value the running build cannot resolve is a hard failure at hydration, not a quietly skipped row. ## Mechanism two: discovering which subtype row exists When no marker is stored, the concrete class is inferred from **where a matching row lives**: the base key appears in exactly one subtype table, and the layer finds out either by outer-joining every subtype table in a single statement and seeing which side came back non-null, or by probing the subtype tables until one answers. - The decision now costs joins or extra round trips, and the cost is proportional to the size of the hierarchy: one more subtype means one more outer join in every base-type read. - Correctness rests on an invariant no single row enforces — exactly one child row per base key. A base key with no child row, or with two, is data the layer can only report as broken. - Reading a **known** concrete type is unaffected: if the caller asks for one subtype by name, the layer goes straight to that subtype's table (plus the base table when the shared columns live there). ## The two side by side | | type marker column | probing subtype rows | |---|---|---| | Cost of the decision | one more column in a read already happening | an outer join or probe per subtype | | Cost of adding a subtype | a new marker value | a wider statement in every base-type read | | Restricting to some subtypes | a predicate on the marker | choosing which tables to join | | Correctness depends on | the marker matching the class registry | exactly one child row per base key | | Typical failure | an unknown marker value | a base row with no child row | ## Consequences worth carrying into review 1. **The decision is per row, not per query.** One base-type result set can mix classes freely; each row is instantiated according to its own marker or its own child row. 2. **It happens before your code sees anything.** By the time results are handed over the classes are fixed, so a wrongly typed object cannot be re-resolved in place — it has to be evicted and read again. 3. **Markers are a deployment coupling.** Every instance that reads the table must know every marker value written to it, which constrains rolling deploys and makes the marker set part of the schema's published contract. 4. **Neither mechanism escapes the hierarchy.** Both make the shape of a base-type read depend on how many subtypes exist; the marker makes that dependency cheap, probing makes it structural. A practical default: use an explicit, stable marker code that is not controlled by the class name, index it if base-type queries are ever narrowed, and treat adding a subtype as a change that touches deployment order as much as it touches schema.