Associations & Fetching

Measure the query count first. If you need whole entities and one collection, page root IDs then fetch the graph by ID. If you need several collections, use batch fetching or separate queries. If you only render fields, use a DTO projection and load no entities at all.

Both make the graph's attributes eager. They differ on everything else: with fetchgraph, attributes not in the graph are lazy regardless of the mapping; with loadgraph, they keep their mapped fetch type, so mapped-EAGER associations still load.

@MapsId makes the child's primary key be the foreign key to the parent — one column doing both jobs. It removes the separate surrogate key and unique constraint, and it fixes the lazy one-to-one problem on the parent side by making the child's ID known in advance.

The mappedBy side has no foreign key column, so Hibernate cannot tell whether a related row exists without querying. A proxy cannot represent "maybe absent", so it queries eagerly. Fixes: a shared primary key with @MapsId, optional = false plus bytecode enhancement, or drop the inverse side.

It makes Hibernate open a temporary session and transaction per lazy access outside the original unit of work. The graph then mixes data from many points in time, every touched object costs a round trip and a connection, and the loud error that used to expose a bad fetch plan disappears.

Tests assert data, not statement counts; fixtures have two or three rows so the extra queries are invisible; entities are already in the persistence context from setup, so no SQL runs at all. Fix: clear the context, seed enough distinct rows, and assert a statement budget.

Cascade only along composition edges inside one aggregate: root to children that have no identity of their own and are referenced by nothing outside. Across aggregate roots, reference by id with no cascade. Wrong boundaries cause shared-data deletion, unbounded graph loads, and hidden write amplification.

Decide per read path, then enforce it. Query-side paths should return projections: no proxies, no over-fetching, explicit contracts. Command-side paths keep entities inside the transaction and never publish them. Whatever the rule, make it mechanical — architecture tests on layer boundaries, statement counts and graph assertions in tests.

Safe: reading its identifier via Hibernate.getId or a property-access id getter, and Hibernate.isInitialized. Anything that needs the row's state is not. Hibernate.initialize forces the load but only works while a session is still open, so it is a tool for building the graph before the boundary, not for rescuing detached objects.

It names which column of the target table the foreign key points at, instead of the default primary key. Use it for legacy schemas keyed on a natural unique column. Cost: the target column needs a unique constraint, and the association no longer resolves through the primary key.

Enhancement rewrites entity classes at build time so field reads are intercepted inside the class itself, instead of relying on a generated subclass. That enables lazy individual attributes, lazy groups, laziness on the inverse side of a one-to-one, and in-line dirty tracking.

Map the @ManyToOne always — it matches the foreign key. Add the inverse collection only when code genuinely navigates parent to children and the collection is bounded. The extra direction costs a consistency invariant, cascade and loading surface, and unbounded collections; the schema is identical either way.

Set a global default around 20-50 as a safety net, then override per association where the shape justifies it. Size trades round trips against IN-list length, plan-cache variance and over-fetching; validate by measuring statement count, rows fetched and latency on realistic data.

Default to Set for owned collections: targeted DML, no delete-all-reinsert, and multiple collections can be fetched in one query. Use indexed lists only where user-defined order is domain data. The price of Set is disciplined equals/hashCode; the price of bags is fetching and write constraints.

Rank by impact: rows returned x call rate x round-trip latency, weighted by user-facing criticality and connection-pool pressure. Fix the top few properly, then prevent recurrence with lazy-by-default mappings, use-case fetch plans or projections, and statement budgets enforced in CI.