How does a mapper's declared cascade of saves and deletes actually execute, and how does that differ from a schema-level cascade?

A cascade declared in a mapping is not a database feature with a mapper-shaped wrapper around it. It is an **in-memory graph walk** the layer performs when it decides what to write: starting from the objects it is tracking, it follows the links marked to cascade, and for each object it reaches it emits the same ordinary statements it would emit if the code had written that object itself. Everything that follows is a consequence of that one fact. ## How the walk runs 1. At flush, the layer walks from each tracked object along links declared to cascade the operation in question — saving, deleting, or both. 2. Each reached object joins the work: a new one becomes an `INSERT`, a changed one an `UPDATE`, a deleted one a `DELETE`. 3. The layer orders the statements so the schema stays satisfied at each step: parents inserted before the children that point at them, junction rows removed before the rows they reference, children deleted before their parent. 4. The statements go out one at a time, or in batches, over the same connection and inside the same transaction as everything else in the unit of work. ## Cascade versus the schema's own rule | | Cascade declared in the mapping | Cascade declared on the foreign key | |---|---|---| | Who executes it | the layer, in application memory | the engine, inside the statement | | What it covers | objects reachable from what the layer is tracking | every row that references the parent, from any client | | Statements produced | one per affected object | one, expanded internally by the engine | | Visible to the tracked set | yes; the layer knows those objects are gone | no; the layer keeps objects for rows that no longer exist | | Paths it misses | bulk statements, direct SQL, other applications | none for that foreign key | The two are not alternatives so much as different guarantees: one keeps the object graph honest, the other keeps the data honest no matter who writes it. Many systems declare both, and then the mapper's deletes run first and the schema rule finds nothing left to do. ## What the walk cannot see - A **bulk statement issued through the layer** — a delete or update over a predicate — is sent to the engine as written. It removes rows without instantiating objects, so no walk happens and no declared cascade runs. It also leaves the tracked set holding objects for rows that are gone. - **Direct SQL**, another service, or an operator at a console are further outside the walk entirely. - Objects the layer never loaded and cannot reach from what it has loaded are not visited, so what the cascade covers depends on what the graph in memory happens to contain. ## Statement count is the operational risk Deleting a parent with ten thousand children through a declared cascade is at least ten thousand and one statements, and the layer must usually load those children to walk to them, so the read cost comes first. For a handful of children this is invisible; at scale it is a long transaction holding locks over a large row set. The remedy is not to fight the cascade but to bypass it for that case: delete the children with one predicate-based statement, then the parent, and accept that the tracked set now holds stale objects — which is fine if the unit of work ends there. ## Unlink is not delete Removing a child from a parent's collection means, by default, **the link is cleared** — the child row survives with a null or unchanged key, depending on which end owns the link. Deleting the detached child is a **separate declaration** (removal of orphans). Getting this wrong in either direction is common: expecting rows to disappear and finding a growing tail of unreferenced children, or expecting a temporary detach and finding the row deleted. And if the link column is not nullable, the plain unlink cannot even be written — the flush fails on a constraint the code never mentioned. ## Half-saved graphs Because the walk emits statements one at a time, a failure partway through leaves part of the graph written. That is harmless when the whole unit of work is one transaction: the rollback removes all of it. It stops being harmless when the code commits inside the loop that builds the graph, when a long import flushes in stages and treats each stage as durable, or when a nested call opens its own transaction for part of the work. Then a constraint violation on the tenth child leaves nine children and a parent committed, and the retry re-inserts what already exists. The rule that keeps this simple: **one graph, one transaction** — and if the graph is too big for one transaction, split it deliberately into units that are each valid on their own, rather than letting the flush boundary decide. ## What an interviewer is listening for That the cascade is the layer's walk, not the engine's; that its coverage is exactly the object graph and therefore excludes bulk and direct writes; that its cost is a statement per object; that unlinking and deleting the orphan are different declarations; and that a half-saved graph is a transaction-boundary bug rather than a mapper defect.