A detached order object with its collection of line items arrives back from a client and the code calls merge() on the order. What determines whether the child rows are written, and what commonly goes wrong with that collection?

## What merge does to a graph `merge` is defined recursively. For the root it resolves a managed target and copies state; for each association annotated with `CascadeType.MERGE` (implied by `ALL`) it repeats the process on the referenced entity or collection elements. Associations without that cascade are treated as plain references: whatever managed instance the copied reference resolves to is used, and if it resolves to nothing persistent you get an error at flush. Three distinct outcomes follow from that definition. **1. Missing cascade.** The order is merged, but a brand-new `OrderLine` hanging off it is not, so at flush Hibernate finds a managed entity pointing at a transient one and throws `object references an unsaved transient instance — save the transient instance before flushing` (`TransientObjectException` / `TransientPropertyValueException`). The fixes are to add `cascade = CascadeType.MERGE`/`ALL`, or to persist the child explicitly. This is the single most-quoted Hibernate error message and interviewers expect you to recognise it instantly. **2. Cost.** Every merged node may cost a SELECT to fetch the copy target. Merging an order with 200 lines can be 201 statements before a single write. Batch imports that merge whole graphs per record are a classic cause of 'the job got slower as data grew'. If the state is genuinely new, `persist` on the root with cascade PERSIST is far cheaper because it never needs to read. **3. Deletion by omission.** This is the dangerous one. `@OneToMany(orphanRemoval = true)` means 'a child no longer referenced by the parent has no reason to exist — delete it'. Merge copies the *incoming* collection contents onto the managed collection, so any child the client did not send is now unreferenced and is deleted at flush. If the client posted only the two lines it edited, the other eighteen are gone. Even worse, if the detached parent's collection was never initialised (the transaction that produced it closed before the collection was touched), the merged collection may end up empty or the association state may be discarded, deleting everything. ## Collection mechanics worth naming Hibernate replaces mapped collections with its own **persistent collection** wrappers (`PersistentBag`, `PersistentSet`, ...) that track additions and removals. Two habits break this: - **Replacing the collection instance** on a managed entity (`order.setLines(new ArrayList<>(incoming))`) throws away the tracked wrapper. Historically this produced `A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance`. The rule is to mutate in place: `lines.clear(); lines.addAll(incoming);`. - **Forgetting the inverse side.** In a bidirectional one-to-many the child owns the foreign key. Merging a parent whose children do not point back at it writes null FKs or leaves orphans; that is why entities carry `addLine(line) { lines.add(line); line.setOrder(this); }` helpers, and why after a merge the fix-up must run against the *returned* managed instances, not the detached ones. ## Optimistic-lock interaction The detached root carries whatever version value it had when it left. Merge copies that value onto the managed instance, so the flush compares the client's version against the row — which is precisely how a stale client edit is rejected. Two consequences: re-merging the same detached instance twice fails the second time, because its version is now behind; and a graph where only children changed will not bump the root's version unless the mapping asks for it. ## The pattern most teams end up with Rather than merging client-supplied graphs, load the aggregate inside the transaction and apply an explicit diff: 1. `Order managed = em.find(Order.class, id);` (with the collection fetched). 2. Compare incoming line identifiers against the managed collection. 3. Update matched lines' allowed fields, add genuinely new ones, remove the ones the request explicitly deleted. 4. Let dirty checking emit the statements. That costs one deliberate query, makes deletion an intent rather than an accident, keeps unmapped or non-editable fields safe from overwrite, and turns 'the client sent a short list' from data loss into a validated decision. Merge on a graph is right when you truly own the whole detached aggregate — an import file, a serialised conversation state — and want insert-or-update semantics for all of it.