Take a whole-part relationship where the part is owned by the whole and dies with it, and assume the in-memory expression of that ownership is already settled. The same claim still gets restated in three other places: the persistence mapping's delete rules (JPA's `cascade` and `orphanRemoval`, Django's mandatory `on_delete` argument, Entity Framework Core's required-versus-optional dependents), the disposal chain (C# `using`/`IDisposable`, Java try-with-resources, Python context managers), and the serialization format (embedding the part's body versus emitting its id). What concretely breaks when those three disagree, and which one do you make authoritative?

## The part of the claim that leaves the object graph Assume the in-memory side is settled: whatever your language uses to say "this part belongs to this whole" has been chosen. The claim does not stop there. The same relationship is written down again, independently, in at least three other places, each with a different enforcement engine and a different failure mode: 1. the **persistence mapping** — the rules deciding what a delete takes with it; 2. the **disposal chain** — who calls close/dispose on the part; 3. the **serialization boundary** — whether the part travels as an embedded body or as an identifier. Nothing keeps these three in agreement. They are usually written by different people on different days, and only the first one is visible when data disappears. ## Layer 1: the persistence mapping This is where the ownership claim is most literally executed, and the frameworks diverge in *what runs and where it runs*, not merely in syntax. - **Django (Python, 2.0+)** makes the decision mandatory: `ForeignKey` will not accept a definition without `on_delete`, so `CASCADE` / `PROTECT` / `RESTRICT` / `SET_NULL` is chosen at declaration time. Crucially, Django does *not* emit an `ON DELETE CASCADE` clause into the foreign-key constraint. Its collector loads the dependent rows into Python, deletes them, and fires `pre_delete`/`post_delete` signals. That means cascades cost queries and honour application logic — and any SQL run outside the ORM cascades nothing. - **JPA/Hibernate (Java)** splits one claim across two independent flags. `cascade = CascadeType.ALL` propagates operations performed on the parent; `orphanRemoval = true` deletes a child that has been detached from the parent's collection. Setting only the first is the classic defect that leaves orphan rows. Bulk JPQL `DELETE` bypasses both, and `@OnDelete(OnDeleteAction.CASCADE)` pushes the rule down into DDL instead — so the same annotation set can mean "the JVM deletes" or "the database deletes". - **EF Core (C#)** infers ownership from nullability: a required dependent defaults to cascade delete, an optional one to severing the reference. It also offers owned entity types, which have no key of their own and no root set — composition raised into the metamodel rather than expressed as a delete rule, which makes a two-owner part unrepresentable. - **Rails (Ruby)** gives the same diamond two runtime meanings: `dependent: :destroy` instantiates each child and runs its callbacks; `dependent: :delete_all` issues one statement and skips them. ## Layer 2: the disposal chain Under tracing collection, memory ignores your model — but sockets, file handles and pooled connections do not. The only executable ownership statement left is *who closes the part*, and the rule is that exactly one holder does. A whole that merely received a shared part must close nothing. The divergence here is whether ownership can be stated at all. .NET makes it a parameter: constructing a reader with `leaveOpen: true` says "I wrap something I do not own". Java's decorators hardcode the opposite — closing a wrapper always closes the wrapped stream, so passing a shared stream into one requires a non-closing shim. Python's `zipfile.ZipFile` closes the underlying file only if it opened it, encoding "I own what I created" as behaviour. Rust removes the decision: destruction runs when the owner goes out of scope, and there is no annotation to forget. ## Layer 3: the serialization boundary Embedding a part's body is an ownership claim; emitting its id is an association. This layer is usually decided for payload-size reasons and then silently contradicts the other two. A part shared by two wholes, embedded in both documents, comes back as two distinct objects; edits to them diverge, and a later deduplication by value merges rows that were meant to differ. Serializers differ on whether identity survives at all: .NET's reference-preserving mode emits `$id`/`$ref` so a shared object stays one object, while the default duplicates it. Jackson's managed/back reference pair drops the child-to-parent link entirely, which is itself a direction-of-ownership statement. ## When the layers disagree The recurring bugs are specific. An ORM cascade plus a database constraint that says something different — bulk SQL then bypasses the application rule and skips audit hooks. Orphan removal enabled on a genuinely shared part — detaching it from one whole destroys data the other still points at. An aggregator disposing a part it borrowed — the other whole gets a closed handle, invisible until a pooled resource is reused. Embed-on-write of a shared part — silent duplication on read. ## Choosing an authority Make the persistence mapping authoritative, because it is the layer that actually destroys data, and derive the rest from it: whoever owns the row owns disposal, and the wire embeds exactly what the mapping owns. Keep a database-level constraint only if it is identical to the mapping's rule, or deliberately weaker — a `RESTRICT`/`PROTECT` net that refuses rather than deletes is safer than a second, subtly different cascade. Note the asymmetry: under-claiming ownership leaves orphan rows and leaked handles, which is recoverable; over-claiming deletes somebody else's data, which is not. So before enabling any cascade, ask whether this part can legitimately belong to a second whole — if it can, no layer may delete it.