How does @MapsId let a JPA @OneToOne share a primary key with its owner, and what problem does that solve compared with a plain @OneToOne @JoinColumn?

## Two ways to map a one-to-one **Plain FK one-to-one:** the child has its own generated primary key plus a foreign-key column to the parent, and you add a unique constraint so it stays one-to-one. ```sql create table user_profile ( id bigint primary key, user_id bigint not null unique references users(id), bio text ); ``` **Shared primary key:** the child has no separate identity at all. Its primary key *is* the parent's key. ```sql create table user_profile ( user_id bigint primary key references users(id), bio text ); ``` The second is strictly smaller: one column instead of two, one index instead of two, and the one-to-one cardinality is enforced by the primary key rather than by a constraint someone must remember to add. ## The @MapsId mapping ```java @Entity class User { @Id @GeneratedValue private Long id; @OneToOne(mappedBy = "user", cascade = CascadeType.ALL, fetch = FetchType.LAZY) private UserProfile profile; } @Entity class UserProfile { @Id private Long userId; // no @GeneratedValue @MapsId // this association supplies the @Id value @OneToOne(fetch = FetchType.LAZY, optional = false) @JoinColumn(name = "user_id") private User user; private String bio; } ``` `@MapsId` says: **derive the identifier from this association.** The `@Id` field is not generated; Hibernate copies the parent's id into it at flush time. Note the `@Id` field carries no `@GeneratedValue` — adding one is a common error that produces a duplicate-key or a mismatched id. When the child key is composite, `@MapsId("attributeName")` names which part of an `@EmbeddedId` the association fills — the same mechanism used for link entities in many-to-many promotions. ## The lazy one-to-one problem This is the reason a senior candidate should know `@MapsId` beyond schema tidiness. On the **owning** side (the one with the FK column), lazy works: the FK value is in the row, so Hibernate can build a proxy keyed on it without querying. On the **inverse** (`mappedBy`) side, the parent's row contains nothing about the child. To create a proxy Hibernate would need the child's identifier, and to know whether the field should be `null` it must know whether a child row exists at all. Since a proxy cannot represent "absent", Hibernate has no choice but to issue a secondary select immediately — the association is effectively eager no matter what `fetch = LAZY` says. Every load of a `User` costs a second query. A shared primary key changes the arithmetic: the child's identifier is the parent's identifier, already in hand. If the association is also declared `optional = false` (a profile always exists), Hibernate may safely return a proxy without checking — nullability was the only remaining unknown. So `@MapsId` + `optional = false` is the combination that actually delivers a lazy inverse one-to-one. The alternatives when you cannot use a shared PK are bytecode enhancement with `@LazyToOne`-style enhanced proxies, or simply not mapping the inverse side and querying the child when you need it. ## Write-time semantics Because identity is derived, ordering matters: ```java User u = new User("ada"); em.persist(u); // id generated here UserProfile p = new UserProfile(); p.setUser(u); // MUST be set — supplies the id p.setBio("..."); em.persist(p); // no id generation; uses u.getId() ``` Persisting the profile without setting `user` fails: there is no identifier to assign. With `cascade = ALL` from the parent and both sides wired, a single `persist(user)` handles it. You also cannot **move** a profile to another user — that would change its primary key, which is an identity change, not an update. If reassignment is a real requirement, the shared-PK model is the wrong model and you want the plain FK with a unique constraint. ## When to use which Use **shared PK / `@MapsId`** when the child is a *dependent extension* of the parent with no independent life: profile, settings, detail rows, an attribute table split off for LOB isolation. Benefits: smaller schema, guaranteed cardinality, lazy inverse side, cheaper joins (PK to PK). Use a **plain FK + unique constraint** when the child has independent identity, can be reassigned, may exist before the parent, or is referenced by other tables under its own key. One caveat worth naming: with `@MapsId` the parent must be persisted (or at least have its id assigned) before the child's identifier is known, which interacts with identity-column generation strategies that only assign on insert. With `SEQUENCE` generation the id is available earlier, which makes batching more predictable.