Associations & Fetching

By default persist applies only to the instance you pass. The new children stay transient, and at flush Hibernate typically fails with "object references an unsaved transient instance". Declaring cascade = PERSIST (or ALL) makes the provider run persist on each child too.

JOIN FETCH tells the ORM to load the joined association's rows into the returned entities in the same SQL statement. A plain JOIN only lets you filter or navigate in the query; the association still loads later on access.

@JoinColumn names the foreign-key column that stores the association. It goes on the owning side — the side whose table holds the FK, which for @ManyToOne is always the many side. The inverse side uses mappedBy instead.

To-one associations (@ManyToOne, @OneToOne) default to EAGER. To-many associations (@OneToMany, @ManyToMany) default to LAZY. The spec assumes fetching one extra row is cheap and fetching a whole collection is not. Most teams override the to-one defaults to LAZY.

One query fetched the 200 orders; touching each order's lazy customer triggered one more query per order, so 1 + N = 201. The cost is dominated by 200 network round trips, not by the work each tiny query does.

mappedBy marks the inverse (non-owning) side and names the owning field on the other entity. Only the owning side — the one holding the foreign-key column, normally the @ManyToOne — produces INSERT/UPDATE of that column. Changing only the inverse collection writes nothing.

When one uninitialised proxy or lazy collection is touched, Hibernate also loads up to N other pending ones of the same type in a single query using where owner_id in (?, ?, ...). It turns N follow-up selects into roughly N/batchSize selects.

PERSIST, MERGE, REMOVE, REFRESH, DETACH, and ALL (all five). Each forwards the matching EntityManager call along the association. Cascading is opt-in because propagation is only correct where the parent truly owns the target — REMOVE especially would destroy shared data.

CascadeType.REMOVE only fires when you explicitly remove the parent — the children go with it. orphanRemoval = true does that too, and additionally deletes a child the moment it is taken out of the parent's collection or its reference is set to null, even though the parent survives.

A List without an index column is a bag: unordered, duplicates allowed, and Hibernate cannot address a row by position. A Set forbids duplicates using equals/hashCode. For collections that own their rows, a bag change often forces a delete-all-then-reinsert; a Set does not.

@ManyToMany with @JoinTable maps a link table of two FK columns: joinColumns points at the owner, inverseJoinColumns at the target; the other side uses mappedBy. Teams replace it with a link entity when the relationship needs its own columns or stable identity.

You hold a proxy: a runtime-generated subclass of the entity that stores only the identifier. Every inherited method call triggers loading of the real row on first use. That requires a non-final class, non-final methods and an accessible no-arg constructor.

A lazy proxy is a generated subclass holding an initializer with the target's identifier and a reference to the Session that created it. The first real getter call triggers a deferred SELECT; if that Session is closed the proxy has no connection to run it, so Hibernate throws instead of silently opening a new one.

find() builds its own fetch plan and can add a join. A JPQL query is executed largely as written, so an EAGER association that is not join-fetched must be satisfied afterwards — one secondary select per distinct associated row. No code needs to touch it.

Fetch join: one query, but duplicates parent rows and breaks database-side pagination. Batch fetching: a handful of IN-clause queries, safe with paging and partial traversal. Subselect: exactly one extra query but replays the parent query and ignores its row limit. Paginated screens use batching; unpaginated full traversal favours join or subselect.

Joining two bags produces a cartesian product, and because bags allow duplicates and carry no index, Hibernate cannot tell real duplicates from join-generated ones. Fix it by mapping the collections as Sets, or by running one query per collection in the same persistence context.

Fix it at the query, not at the point of failure. Best: select exactly the fields you need into a DTO. Next: load the entity with a fetch join or entity graph so the needed associations arrive in one query. Acceptable: touch what you need while the context is open. Never: force loading after the fact.

Measure statements per logical operation, not query duration. Turn on SQL logging (org.hibernate.SQL), or Hibernate Statistics for counts, or wrap the DataSource with datasource-proxy/p6spy to count and assert per request. Then vary the row count and see whether the count scales with it.

Because a bidirectional pair is one relationship stored in two fields, and both must agree. A helper sets the owning reference and updates the inverse collection in one call, so writes reach the foreign key and the in-memory graph stays truthful for the rest of the session.

SELECT loads the association with a separate query when it is needed; JOIN loads it in the same statement with an outer join. JOIN applies only when Hibernate builds the SQL itself — find and navigation — and is ignored by JPQL, HQL and Criteria queries, which use their own explicit fetch plan.

@OrderBy adds an ORDER BY clause when the collection loads — nothing is stored, and the collection stays a bag. @OrderColumn persists each element's position in a dedicated column, making it an indexed list, which costs extra UPDATEs whenever positions shift.

An entity graph is a reusable, declarative description of which attributes to load with a query. Define it with @NamedEntityGraph on the entity or build it via em.createEntityGraph(Class), then pass it to a query or find() as a hint.

The provider creates a join table instead of a foreign key in the child table — the default for a unidirectional one-to-many. Alternatives: add @JoinColumn to keep the FK in the child (costs extra UPDATEs), or make it bidirectional with mappedBy, which is cleanest.

Use Hibernate.isInitialized(x) (or PersistenceUnitUtil.isLoaded) to test without loading, Hibernate.initialize(x) to force the load while a session is open, and Hibernate.unproxy(x) to get the real instance behind a proxy.

The side declaring @JoinTable owns it; the other uses mappedBy and never writes. Removing from a Set-typed owning collection emits one targeted DELETE of that link row. With a List (bag), Hibernate deletes every link row for that owner and re-inserts the survivors.

When any one collection from a previously-run query's results is initialised, Hibernate loads that collection for all those parents in one query, re-using the original query as a subselect in the WHERE clause. It needs the original query still tracked in the same session, and applies to collections only.

CascadeType.MERGE decides whether the children are merged at all — edited ones update, new ones become inserts. The dropped line is deleted only if the association declares orphanRemoval = true; otherwise its row survives. And merge returns a managed copy: your detached object stays detached.

Because the target is shared. Removing one post would delete tags other posts still use, or on a @ManyToOne would delete the parent and, through it, every sibling. Cascade must only follow edges where the source truly owns the target.

The collection is a bag: a List with no index column. Hibernate cannot tell which row an element corresponds to, so it recreates the whole collection. Fix it by mapping the collection as a Set, adding @OrderColumn, or making a one-to-many bidirectional with orphanRemoval.