A developer maps a one-to-many collection in JPA with only @OneToMany and no mappedBy or @JoinColumn. What schema does the provider generate, why is that surprising, and what are the alternatives?

## The surprise ```java @Entity class Parent { @Id @GeneratedValue private Long id; @OneToMany(cascade = CascadeType.ALL) private List<Child> children = new ArrayList<>(); } ``` Nothing here says `mappedBy` and nothing says `@JoinColumn`. Most developers assume the generated schema is `child(parent_id)`. It is not. JPA's default for a unidirectional to-many association is a **join table**: ```sql create table parent_children ( parent_id bigint not null references parent(id), children_id bigint not null references child(id), primary key (parent_id, children_id), unique (children_id) -- keeps it one-to-many, not many-to-many ); ``` The unique constraint on the child column is what distinguishes this from a many-to-many: a child may appear under at most one parent. ## Why it is a bad default in practice - **An extra table** nobody designed, usually with a provider-generated name that leaks the Java field name (`parent_children`, `children_id`). - **An extra join** on every read that navigates the association, and two indexes to maintain instead of one. - **Extra writes**: inserting a child costs an insert into `child` *and* an insert into `parent_children`. - **Weaker integrity**: the parent link is enforced in a side table, so you cannot express "a child must have a parent" with a simple `not null` on the child row. - **Worse deletes**: removing an element deletes a link row and leaves an orphan child unless `orphanRemoval` is on. The spec chose it because a unidirectional one-to-many has no field on the child to hold the FK, and a join table is the only mapping that requires no knowledge on the child side. It is principled; it is just rarely what you want. ## Option 1 — @OneToMany with @JoinColumn ```java @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true) @JoinColumn(name = "parent_id") private List<Child> children = new ArrayList<>(); ``` This produces the schema you expected: `child.parent_id`. But the *parent* owns the association while the FK lives in the *child* row, and Hibernate resolves that by writing in two passes: ```sql insert into child (id, name, parent_id) values (?, ?, null); update child set parent_id = ? where id = ?; ``` One extra `UPDATE` per child, and `parent_id` must be nullable, so the database cannot enforce that every child has a parent. Removing an element issues `update child set parent_id = null` (or a delete with `orphanRemoval`). For small collections this is tolerable; for bulk inserts it doubles the statement count. Adding `@JoinColumn(nullable = false)` does not fix it — the null-then-update sequence would violate the constraint. ## Option 2 — bidirectional (recommended) ```java @Entity class Child { @ManyToOne(fetch = FetchType.LAZY, optional = false) @JoinColumn(name = "parent_id", nullable = false) private Parent parent; } @Entity class Parent { @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true) private List<Child> children = new ArrayList<>(); void addChild(Child c) { children.add(c); c.setParent(this); } void removeChild(Child c) { children.remove(c); c.setParent(null); } } ``` The child owns the FK, so each child is written with one INSERT carrying `parent_id`. The column can be `not null`, giving the database real integrity. The cost is the discipline of keeping both sides in sync — hence the helper methods, which are not optional decoration but the mechanism that prevents the classic "FK stayed null" bug. ## Option 3 — no collection at all If the child count is unbounded (audit rows, events, messages), mapping a collection at all is a liability: it invites accidental full loads, `orphanRemoval` semantics you do not want, and cascade behaviour on delete that locks huge row sets. Map only `Child.parent` and query `select c from Child c where c.parent = :p` with pagination. Dropping the parent-side collection is a legitimate and frequently correct answer, and mentioning it signals design maturity. ## How to notice this in a real codebase The join table usually appears when someone lets the provider generate DDL in development. If migrations own the schema (Liquibase/Flyway) the mapping and the schema silently disagree, and you get a runtime failure — "table parent_children does not exist" — rather than a bad schema. Either way, the diagnosis is the same: a `@OneToMany` with neither `mappedBy` nor `@JoinColumn`.