Why does comparing mapped objects by reference identify a row reliably inside one tracked set but not across two?

## Why reference comparison works at all here Comparing two references asks whether they point at the same object in memory. That is normally a much stronger question than "do these describe the same database row", and normally the wrong test. Inside a tracked set it happens to be exactly right, because the identity map enforces **one object per row key for the life of the set**: if two references describe the same row, the map guarantees they *are* the same reference. So reference comparison is not a hack inside one set — it is the cheapest correct identity test available, and it is why so much mapper-backed code contains it. ## Why it stops being right at the boundary The guarantee is scoped to one set, and nothing outside a set enforces anything. Two references to one row appear whenever: - two tracked sets are open at once, each having materialised the row; - an object was loaded by an earlier set, kept, and is now compared with one loaded by the current set; - an object came back from another layer — a queue, a cache of your own, a call boundary — and is compared with a freshly loaded one; - an object was rebuilt from a transfer shape rather than loaded at all. In every one of those cases the two objects describe one row and are different objects, so reference comparison answers "no" to a question whose true answer is "yes". ## What that breaks, concretely - **Membership tests** report absent for an element the collection describes. - **Deduplication** by identity keeps two entries for one row, so a batch writes twice or a total counts twice. - **Identity-keyed maps** — a lookup side table keyed by the object — miss, and the code takes the "not seen yet" branch. - **Removal** from a collection silently does nothing, because the element to remove is not the element held. These failures share a signature: nothing throws, the wrong branch is simply taken, and it only happens on paths where an object crossed a boundary. That is why they escape tests written entirely inside one set. These failures also tend to appear late, because the boundary that produces the second instance is often introduced long after the comparison was written: a job is split out, a caching layer is added, a call becomes asynchronous. The comparison did not change; the guarantee under it did. ## What to compare instead | Test | Correct when | Fails when | |---|---|---| | Reference comparison | Both operands loaded by the same tracked set | Operands come from different sets or were rebuilt | | Identifier comparison, type included | Both operands are saved rows | Either operand has no key assigned yet | | A natural business key, when the model has a real one | Any operands, including unsaved | The model has no genuinely unique, immutable business key | Identifier comparison is the workhorse: include the type, because the number 7 names a row in every table. Where the model genuinely has an immutable natural key, comparing on it is stronger still, because it also works before a key is assigned. ## The unsaved-object trap An object created in memory has no key yet. If it goes into a hash-based collection while its hash derives from that key, and the key is then assigned when the object is written, the object's hash changes while it sits in the collection — and the collection can no longer find it, including to remove it. There are two honest ways out: keep hashing stable and independent of the assigned key, or keep unsaved objects out of hash-based collections until they have one. The first is usually preferred because it survives every path an object can take; the second depends on nobody forgetting. When the key is assigned, and by what mechanism, is a separate topic; the consequence here is only that it can appear *after* the object exists. ## Interview framing Say the scope out loud: reference comparison is a correct identity test *inside one tracked set* and a broken one outside it, because the one-object rule is what made it correct in the first place. Then name the boundary cases that produce a second instance, describe one silent failure — a membership test that misses — and give the rule you actually apply: compare by identifier wherever operands might not share a set. That answer shows you understand the guarantee rather than having memorised a prohibition.