In a bidirectional JPA association, what does the `mappedBy` attribute mean, and which side's changes actually cause Hibernate to write the foreign key?

## The problem mappedBy solves A bidirectional association is two Java fields describing **one** database column. `Order.customer` and `Customer.orders` are not two relationships; they are two views of the `orders.customer_id` column. If both were treated as independent sources of truth, the ORM would have to reconcile them on every flush — and would have no rule for what to do when they disagree (customer A's collection contains an order whose `customer` field points at customer B). JPA solves this by decree rather than reconciliation: **one side owns the mapping, the other is declared inverse with `mappedBy`, and only the owner is consulted when generating SQL.** ## Reading a mappedBy declaration ```java @OneToMany(mappedBy = "customer") private Set<Order> orders; ``` The value `"customer"` is the **name of the Java field on the other entity** that owns the mapping — here `Order.customer`. It is not a column name and not a table name. Getting it wrong is a boot-time mapping failure, which is helpful: the mistake surfaces immediately. A field annotated with `mappedBy` may not also carry `@JoinColumn` or `@JoinTable`; those describe the physical mapping, and the inverse side has none. If you find yourself wanting both, you have two owners and therefore two independent mappings for one column — Hibernate will happily generate a redundant, sometimes conflicting, extra UPDATE. ## Who owns what - `@ManyToOne` / `@OneToMany`: the `@ManyToOne` side always owns, because the FK lives in its table. The collection side is always `mappedBy`. - `@OneToOne`: whichever entity's table holds the FK owns it; the other uses `mappedBy`. With `@MapsId` the dependent (shared-PK) side owns. - `@ManyToMany`: the side declaring `@JoinTable` owns; the other uses `mappedBy`. The choice is arbitrary from the schema's point of view, so pick the side whose code does the writing. - Unidirectional associations have no inverse side at all; the single mapped side owns by definition. ## What "generates SQL" really means At flush time Hibernate compares each managed entity against the snapshot it took when the entity was loaded, and derives the SQL. For an association, the state it inspects is the **owning** field. So: ```java customer.getOrders().add(order); // in-memory only; no FK write order.setCustomer(customer); // this is what produces the UPDATE/INSERT ``` Set only the inverse collection and the row's `customer_id` stays null (or unchanged) — the classic "my save silently did nothing" bug. Worse, within the same persistence context the collection *looks* right, because you mutated it yourself; the truth only appears after a clear, a new transaction, or a reload. That is why the failure so often escapes tests that assert inside the same session. Set only the owning side and the data is correct, but the other entity's collection in memory is stale for the rest of the session. This is the milder bug, and the reason for the sync-helper convention that keeps both fields consistent in one call. ## Special cases worth knowing **Inverse collection with cascade.** Cascading from the inverse side still works — cascade follows Java references, not ownership — so `persist` can reach children through a `mappedBy` collection. But cascade only makes the children persistent; it does not set their FK. A cascaded child with a null owning reference will still be inserted with a null `customer_id`, or fail the NOT NULL constraint. **Unidirectional `@OneToMany` without `@JoinColumn`.** With no owner on the many side and no explicit `@JoinColumn`, JPA defaults to a join table, which is usually a surprise and produces extra delete/insert traffic. Either add `@JoinColumn` (making the collection the owner of the FK, with its own quirks) or, preferably, map the `@ManyToOne` and let it own. **Both sides mapped as owners.** Two `@JoinColumn`s on the same column with no `mappedBy` yields two mappings that both write; Hibernate emits an extra UPDATE and the two can fight. Adding `insertable = false, updatable = false` to one is the read-only escape hatch, but `mappedBy` is the correct expression of intent. ## How to answer in an interview Say it in one sentence — "`mappedBy` names the owning field on the other entity and marks this side as a non-writing view" — then give the failing snippet, then name the two symptoms: null foreign key when you set only the inverse side, stale collection when you set only the owning side. That progression demonstrates you have actually debugged it rather than memorised it.