When a partially populated object is copied into a tracked set, how are its nulls, absent collection elements and linked objects treated?

Copying a detached object's state into a tracked set is a **replace**, not a patch. That single sentence explains most of the surprises, and most of the data loss, that this mechanism produces. The layer walks the mapped fields of the object you hand it and assigns each value onto the tracked instance for that key. It has no way to know which of those values you meant and which merely defaulted, because an unset field and a deliberately cleared field look identical in memory. ## Scalar fields and nulls If the object you hand in carries a null for a column that currently holds a value, the assignment stores null and the old value is gone at the next flush. There is no heuristic that skips empty values — skipping nulls is patch semantics, and if you want it you write it yourself in a mapping step. This turns a very ordinary-looking pipeline into data loss: - An update request arrives carrying three fields the user actually edited. - A transfer model is populated from it, so the other fifteen mapped fields are null or zero. - That object is copied in, and fifteen columns are wiped. The request looked partial; the write was total. Nothing in the layer complained, because from its point of view it faithfully stored what it was given. ## Collections Collections follow the same logic one level up: the tracked association is made to look like the collection you handed in. An element present in the tracked collection but absent from yours is unlinked. Whether the row behind that element is then **deleted** or merely left disconnected is not a property of the copy-in — it is decided by the mapping: - If the mapping says children that lose their parent should be deleted, the unlinked row is removed. - If it does not, the row survives with a dangling or nulled reference, which is often worse than either intended outcome because nothing points at it any more. - If the incoming collection was never populated at all — a common accident when a transfer model omits it — an empty collection is still a collection, and the layer reads it as "make this association empty". ## Links to other objects The copy does not travel everywhere it can reach. It travels where the mapping says to **cascade** it: | Situation | What happens to the linked object | |---|---| | Association cascades the copy, child is detached | the child's state is copied onto its own tracked instance | | Association cascades the copy, child is new | it is brought in with the parent | | Association does not cascade, child is detached | the layer ignores it, or refuses the untracked reference — layers differ | | Association does not cascade, child is already tracked | the link is set; the child's own values come from wherever it was edited | The failure mode here is the mirror of the null one: a child object you fully expected to be saved silently is not, because nobody configured the link to carry the copy. It is worth reading cascade settings as part of reviewing any write path that hands a whole object graph to the layer. ## What to do instead The safest habit is to keep partial inputs away from whole-object copies entirely: 1. **Load the row inside the unit of work.** One read, by key, in the same piece of work that will write. 2. **Apply only what the caller actually sent.** If the protocol can distinguish "field absent" from "field set to empty", preserve that distinction all the way down to the assignment; if it cannot, decide explicitly which one absence means and document it. 3. **Let change detection produce the write.** Having edited a tracked object, you need no copy-in at all — the flush writes exactly the fields that changed. Where a whole-object copy-in genuinely is the right tool — a full-replacement update, an import that owns every column — make that explicit in the contract, and make sure the object being copied really is complete, ideally by building it from a full read rather than from a request body. ## The contract question underneath Ultimately this is not a mapper question but an interface one. "Update this thing" is ambiguous: it can mean *here is the new state of the whole thing* or *here is what changed*. Whole-object copy-in implements the first. Loading and applying a delta implements the second. Data is lost whenever the write path implements one and the caller believes the other, so the useful discipline is to name which one you are offering before you decide how to persist it.