Unit of Work Mechanics

Detaching removes the object from change tracking: later edits are no longer noticed or written, edits not yet flushed are usually lost, and links left as unresolved stand-ins have no set behind them to load through.

A flush turns the unit of work's accumulated in-memory changes into SQL statements sent on the already-open transaction. A commit ends that transaction, making the changes durable and visible to others. Flushed-but-uncommitted work is still discarded by a rollback.

You get the same object both times. A tracked set's identity map, keyed by type plus identifier, makes one row exactly one object for the life of that set; a by-key lookup it already holds needs no statement.

Transient means never stored and not watched. Managed means the tracked set holds it and will write its edits. Detached means it once was managed but its set has ended. Removed means a delete is planned.

Opening a unit of work borrows a pooled connection; every statement it runs travels over that connection; closing hands it back, still established. A unit that is never closed keeps holding it, and the pool drains.

Snapshot comparison keeps original values and diffs them at flush: general, but costs a second copy and a full scan. Notification has instrumented members report each write, keeping a dirty set incrementally. Explicit marking makes the code name the write.

Reattaching makes the very instance you hold tracked again. A copy-in instead resolves the row's own instance, assigns your values onto it and returns that one, leaving the object you passed in detached forever.

A query is evaluated by the database, which knows nothing about unwritten in-memory edits, so its filters ignore them. Many layers therefore flush pending changes before an affected query; that cannot help statements the layer never sees.

Normally the held object, edit intact - not the columns the database just sent. The layer reconciles each returned row against its identity map and hands back the instance it already holds, dropping the freshly read values.

It infers newness from a signal: an unset generated key, an absent version value, or a probe read for the row. Each signal can guess wrong or costs a round trip, which is why explicit insert calls exist.

The three scopes differ in how long the tracked set and its connection stay alive - one transaction, one request, or a flow spanning requests. Longer scopes reuse more objects, go stale more often, and hold a shared connection longer.

Comparison misses an edit when the snapshot shares a mutable reference with the object, so both change together. It reports a false change when a value never round-trips equal: truncated precision, collation folding, or equality that ignores fields.

A copy-in overwrites the target field by field, so a null in the incoming object stores a null, a collection is made to match the one handed in, and links are followed only where the mapping cascades the copy.

Because the second read is served from the identity map: it returns the object already held, so the reads agree by instance reuse, not by an engine guarantee. The held object can still be stale.

A cascade applies one object's state transition to the objects reachable through links declared to cascade, so one save or delete becomes many. It reaches too far when it crosses a link to shared data that other rows still need.

Acquisition timing decides how much of a boundary's duration occupies a pool slot. Taking the connection at the boundary is predictable but pays for pre-work; taking it at the first statement lets a boundary that never queries borrow nothing.

Tracking holds each row twice, object plus snapshot, and every flush compares the whole accumulated set, so cost grows as the read proceeds. Read untracked, or project the needed columns into an unmapped shape, so no original values are kept.

The detached object is a snapshot of the row an hour earlier, and writing it back assigns every mapped field, so a column another writer changed is overwritten with the old value and the update still succeeds.

The unit of work does not replay statements in call order; it groups them by kind and dependency, sending inserts before deletes. So the replacement meets the original still holding the key. Flushing between them forces the order.

Very little. Some statements were sent, one failed, the rest never attempted, and the tracked set no longer describes any real state. Treat it as unusable, and never reuse its objects as if they were saved.

Inside one tracked set the identity map guarantees one instance per row, so reference comparison is a valid row-identity test. Across two sets one row has two instances and the test reports 'different' - compare by identifier at that boundary.

Each set has its own identity map, so one row becomes two drifting objects: edits in one are invisible in the other, and the later write can overwrite the earlier. One set per operation, plus a version check, contains it.

The layer only knows about writes it made itself. A statement sent around it moves the rows while tracked objects keep their old values and old version numbers, so a later write-out can overwrite the newer row.

Convenience: deferred links still resolve while the view walks the object graph, so nobody declares in advance what a screen needs. It costs a connection held through the slowest phase and statements issued from a layer nobody reviews.

Automatic detection makes the write set a runtime property no reviewer can see, so incidental assignments become real statements. Explicit marking makes writes visible at the cost of discipline: a forgotten mark loses data silently. Choose per path.

Default to flushing at the transaction boundary; treat an explicit flush as a rare exception with a stated reason. Forcing one early takes row locks sooner and holds them to commit, gives up grouping, and moves where errors surface.

Set policy per workload against one invariant: a unit of work is open only while it is issuing statements. Requests get a thin boundary; batches one unit per chunk with the tracked set discarded between chunks; flows keep detached state.

Default to a generic save where the store assigns keys and writes are ordinary edits; require explicit inserts and updates where the application assigns keys, writes are high volume, or creating an existing thing must fail.