When a detached object rejoins a tracked set, how does reattaching that instance differ from copying its state onto a freshly loaded one?

A detached object is an ordinary in-memory object that happens to carry the key of a row and a set of field values read at some earlier moment. To get those values into the database it has to come under the control of a live **unit of work** again, and data-access layers offer two shapes for that. They look interchangeable in a code review and are not. ## Route one: reattach the instance you hold Reattaching takes the object you are holding and makes it a member of the current tracked set. Afterwards the reference in your hand is the managed one: later assignments to its fields are noticed by change detection and written at the next flush, exactly as if you had loaded it here. - The instance's address does not change; nothing is copied. - The layer has to establish a baseline for change detection. Some layers assume the whole object is dirty and write every mapped field; others read the row's stored state and write only the differences. Either way, all the values the instance carries are candidates to be written. - Because an **identity map** allows at most one tracked object per row, reattaching is only possible when the set does not already hold an instance for that key. A second claimant cannot also be adopted. ## Route two: copy the state in A copy-in does not adopt your object at all. The layer resolves the tracked instance for that key — finding it in the identity map, or reading the row if it is not loaded — assigns the incoming field values onto it, and hands that instance back to you. Your object stays detached for the rest of its life. - It works when the set already holds the row, because it writes into the instance already held instead of competing with it. - It usually costs a read that reattaching does not, unless the target was already loaded. - The returned reference is the only tracked one. This is the whole trap. ## The two routes compared | | Reattach | Copy-in | |---|---|---| | Which object ends up tracked | the one you passed in | the set's own instance for that key | | What the caller should hold afterwards | the same reference as before | the reference the call returned | | Set already holds that row | conflict — one row, one instance | fine, values land on the held instance | | Extra read | often none | usually one, unless already loaded | | Your original object | is the live one | stays detached forever | ## The bug this distinction causes The classic symptom is a save that appears to do nothing. The code copies an object in, then continues editing the object it passed in — setting a status, stamping a timestamp — and commits. Those later edits land on a detached object that nothing is watching, so they are never written, while the values captured at the moment of the copy-in are. Nothing throws. The row is updated, just not with everything the code believed it had set. The fix is mechanical and worth making a house rule: 1. Assign the result of a copy-in to a variable and keep working with that. 2. Do not keep the input object in scope afterwards if you can avoid it; shadowing or reassigning removes the temptation. 3. In review, treat a copy-in whose return value is discarded as a defect on sight. ## Choosing between them Reattaching is attractive when the object genuinely round-tripped from this system and you want the same reference to stay live, and when you know nothing else in the current work has loaded that row. Copy-in is the more forgiving of the two precisely because it does not care what the set already holds, which is why it tends to be the default in code that receives objects from elsewhere. The deeper answer in an interview is that both are compromises. Whole mapped objects travelling outside the set and coming back is what creates the question at all. A write path that accepts a description of the change, loads the row inside the unit of work, and applies the change to the loaded object never has to explain the difference between the two routes to anyone — and never has to explain, either, why the object somebody kept editing did not save.