Hibernate One-to-Many Mapping: JPA @OneToMany Explained

A Hibernate one-to-many mapping links one parent entity to many child entities, for example one bank account to all its payments. In the database, the link is a foreign key column in the child table (account_id in the Payment table), and in Java, the parent holds a collection of children annotated with @OneToMany. The recommended form is bidirectional, with @OneToMany(mappedBy) on the parent and @ManyToOne on the child, which we keep in sync with two helper methods.

We use a one-to-many mapping whenever one record owns a list of others, such as a customer and its addresses or a playlist and its songs.

The following example maps an account with many payments, and then saves, loads and removes payments.

// Account (parent)
@OneToMany(mappedBy = "account", cascade = CascadeType.ALL, orphanRemoval = true)
private List<Payment> payments = new ArrayList<>();

public void addPayment(Payment payment) {
  payments.add(payment);
  payment.setAccount(this);
}

public void removePayment(Payment payment) {
  payments.remove(payment);
  payment.setAccount(null);
}

// Payment (child): owns the account_id foreign key
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "account_id")
private Account account;

Account account = new Account("Lokesh");
account.addPayment(new Payment("Rent", "1200.00"));
account.addPayment(new Payment("Groceries", "85.50"));
account.addPayment(new Payment("Coffee", "4.00"));
em.persist(account);                       // insert into Account (owner,id) values (?,default)
                                           // 3 x insert into Payment (account_id,amount,description,id) ...

// in a later transaction
Account loaded = em.find(Account.class, id);   // select ... from Account a1_0 where a1_0.id=?
int count = loaded.getPayments().size();       // 3: select ... from Payment p1_0 where p1_0.account_id=?
loaded.removePayment(loaded.findPayment("Coffee"));   // delete from Payment where id=?

Notice that persist() on the account also inserts the three payments, and removing a payment from the list deletes its row.

Next, we map an account and its payments in all three ways JPA allows and compare the SQL each one sends. After that, we answer the common questions, such as null foreign keys and N+1 selects.

1. What Is a One-to-Many Mapping in Hibernate?

A one-to-many association means that one row of the parent table relates to many rows of the child table, and each child row belongs to at most one parent. So one account has many payments, but each payment is paid from one account only. Account and Payment are both entities (Java classes mapped to tables with @Entity).

The database stores the relationship in one place only, the account_id foreign key column in the Payment table. When both entities point to each other, Hibernate needs to know which Java field decides the value of that column.

• The owning side is the field whose value Hibernate writes to the foreign key. In a bidirectional one-to-many, it is always Payment.account (the @ManyToOne side).
• The inverse side is the collection marked with mappedBy. Hibernate fills Account.payments when it loads the account, but never writes account_id from it.

The value of mappedBy is the name of the Java field on the child, not a column name. For example, mappedBy = “account” points to Payment.account.

JPA offers three ways to map the same relationship. A bidirectional mapping has a field on both sides, whereas a unidirectional mapping has a field on the parent only, so the account knows its payments but a payment does not know its account. The three ways differ in which side owns the foreign key and in how many SQL statements Hibernate runs.

Mapping	Annotations	Tables	Save 1 account + 3 payments	Remove 1 payment
Bidirectional (recommended)	@OneToMany(mappedBy) + @ManyToOne	Account, Payment	4 inserts	1 delete
Unidirectional with join column	@OneToMany + @JoinColumn	Account, Payment	4 inserts + 3 updates	1 update + 1 delete
Unidirectional with join table	@OneToMany only	Account, Account_Payment, Payment	7 inserts	1 delete + 2 inserts + 1 delete

2. One-to-Many Mapping Example

We map a bank account and its payments with Hibernate 7.4, Java 25 and an H2 in-memory database, and run each mapping from the table in section 1.

2.1. Domain Model

An account has an owner (“Lokesh”) and a list of payments. Each payment has a description, an amount and the account it was paid from, and a banking app shows these payments as the account statement.

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

private String owner;

@OneToMany(mappedBy = "account", cascade = CascadeType.ALL, orphanRemoval = true)
@OrderBy("amount desc")
private List<Payment> payments = new ArrayList<>();

// addPayment() and removePayment() as shown above

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

private String description;
private BigDecimal amount;          // new Payment("Rent", "1200.00")

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "account_id")
private Account account;

The helper methods addPayment() and removePayment() change both sides in one call. Without them, we can update the collection and forget the owning field, which is the field Hibernate saves (see FAQ 3.1). The project also has a small findPayment(description) helper that returns a payment from the list by its description. Each attribute in the mapping controls one part of the behavior.

Attribute	Where	What it does
mappedBy = “account”	@OneToMany	Marks the collection as the inverse side of Payment.account
cascade = CascadeType.ALL	@OneToMany	persist(), merge(), remove() and the other operations on the account also apply to its payments
orphanRemoval = true	@OneToMany	A payment removed from the list is deleted from the table
@OrderBy(“amount desc”)	Collection	Adds order by to the SQL that loads the payments
fetch = FetchType.LAZY	@ManyToOne	Loads the account of a payment only when we use it (the default is EAGER)
@JoinColumn(name = “account_id”)	@ManyToOne	Names the foreign key column in the Payment table

Hibernate creates this schema from the two entities.

create table Account (id bigint generated by default as identity, owner varchar(255), primary key (id))
create table Payment (amount numeric(38,2), account_id bigint, id bigint generated by default as identity, description varchar(255), primary key (id))
alter table if exists Payment add constraint FKjiyk2ty9k4v31oo83q8sxo5ka foreign key (account_id) references Account

2.2. Saving an Account With Its Payments

We call persist() only for the account. CascadeType.ALL passes the call on to every payment in the list, and each payment already knows its account, so its insert contains the foreign key.

emf.runInTransaction(em -> {
  Account account = new Account("Lokesh");
  account.addPayment(new Payment("Rent", "1200.00"));
  account.addPayment(new Payment("Groceries", "85.50"));
  account.addPayment(new Payment("Coffee", "4.00"));
  em.persist(account);
});

insert into Account (owner,id) values (?,default)
insert into Payment (account_id,amount,description,id) values (?,?,?,default)
insert into Payment (account_id,amount,description,id) values (?,?,?,default)
insert into Payment (account_id,amount,description,id) values (?,?,?,default)

Without a cascade, we must call em.persist() for each payment ourselves. The other JPA cascade types pass other operations, such as merge() and remove(), from the account to its payments in the same way.

2.3. Loading the Payments of an Account

A @OneToMany collection is LAZY by default. The call em.find() loads only the account, and Hibernate reads the payments when we first use the list. The annotation @OrderBy sorts them in the same query.

Account account = em.find(Account.class, accountId);
// select a1_0.id,a1_0.owner from Account a1_0 where a1_0.id=?

int count = account.getPayments().size();          // 3
// select p1_0.account_id,p1_0.id,p1_0.amount,p1_0.description from Payment p1_0
//   where p1_0.account_id=? order by p1_0.amount desc

List<Payment> payments = account.getPayments();    // [Rent 1200.00, Groceries 85.50, Coffee 4.00]

The second query runs inside the same transaction, because reading the list after the transaction has ended throws LazyInitializationException (see FAQ 3.4). The same lazy loading applies to the @ManyToOne field, because we set fetch = FetchType.LAZY on it.

2.4. Removing a Payment

The helper removePayment() takes the payment out of the list and clears its account field. Because the mapping has orphanRemoval = true, Hibernate deletes the row at commit. For example, the owner cancels the Coffee payment before the bank books it.

emf.runInTransaction(em -> {
  Account account = em.find(Account.class, accountId);
  account.removePayment(account.findPayment("Coffee"));
});                                     // delete from Payment where id=?

Without orphanRemoval, the same code only sets account_id to NULL, so the payment row stays in the table as an orphan that belongs to no account.

2.5. Unidirectional One-to-Many With @JoinColumn

When the payment has no account field, the parent becomes the owning side. The annotation @JoinColumn on the collection tells Hibernate to keep the foreign key in the Payment table, so the tables stay the same as in section 2.1.

@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "account_id")
private List<Payment> payments = new ArrayList<>();

account.getPayments().add(new Payment("Rent", "1200.00"));   // no helper needed

The payment does not know its account, so Hibernate inserts it without the foreign key and fills account_id afterwards with one UPDATE per payment.

insert into Account (owner,id) values (?,default)
insert into Payment (amount,description,id) values (?,?,default)
insert into Payment (amount,description,id) values (?,?,default)
insert into Payment (amount,description,id) values (?,?,default)
update Payment set account_id=? where id=?
update Payment set account_id=? where id=?
update Payment set account_id=? where id=?

update Payment set account_id=null where account_id=? and id=?
delete from Payment where id=?

2.6. Unidirectional One-to-Many With a Join Table

A @OneToMany without mappedBy and without @JoinColumn makes Hibernate create a join table, a third table that holds only pairs of foreign keys.

@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
private List<Payment> payments = new ArrayList<>();

create table Account_Payment (Account_id bigint not null, payments_id bigint not null unique)
alter table if exists Account_Payment add constraint FKsei2xjt62nf2atbumltybmko4 foreign key (payments_id) references Payment
alter table if exists Account_Payment add constraint FKrtncxgwqnc46edxgyguo9vwmk foreign key (Account_id) references Account

The default names follow the JPA rules. The table is Account_Payment (owner entity first). The column Account_id is the entity name plus its key column, and payments_id is the collection field name plus the key column of Payment. The unique constraint on payments_id keeps a payment in one account only. We can rename all three with @JoinTable.

Saving the same account writes three extra rows into the join table.

insert into Account (owner,id) values (?,default)
insert into Payment (amount,description,id) values (?,?,default)
insert into Payment (amount,description,id) values (?,?,default)
insert into Payment (amount,description,id) values (?,?,default)
insert into Account_Payment (Account_id,payments_id) values (?,?)
insert into Account_Payment (Account_id,payments_id) values (?,?)
insert into Account_Payment (Account_id,payments_id) values (?,?)

Removing one payment costs even more. A List without an index column is a bag for Hibernate, and its rows have no position or key that identifies one link. So Hibernate deletes every join table row of the account and inserts the remaining ones again.

delete from Account_Payment where Account_id=?
insert into Account_Payment (Account_id,payments_id) values (?,?)
insert into Account_Payment (Account_id,payments_id) values (?,?)
delete from Payment where id=?

Loading the payments also needs a join of two tables instead of one.

select p1_0.Account_id,p1_1.id,p1_1.amount,p1_1.description
from Account_Payment p1_0 join Payment p1_1 on p1_1.id=p1_0.payments_id where p1_0.Account_id=?

A join table makes sense for a many-to-many mapping, which needs one, but for one-to-many we prefer the bidirectional mapping from section 2.1.

The complete project on GitHub runs all three mappings and prints the SQL, and 11 JUnit tests check every statement count from section 2 (mvn -q compile exec:java, mvn test).

3. One-to-Many Mapping FAQs

3.1. Why Is the Foreign Key Column NULL After Saving?

We added the child to the parent’s collection but did not set the child’s @ManyToOne field. Hibernate writes account_id from the owning side only, so the payment is saved without its account.

// Wrong: only the inverse side is set
account.getPayments().add(new Payment("Books", "30.00"));
// insert into Payment (account_id,amount,description,id) ...   account_id = null

// Right: the helper sets both sides
account.addPayment(new Payment("Books", "30.00"));

The cascade still inserts the payment, so there is no error. The row is saved with account_id = NULL, and the next time we load the account, the payment is missing from the list.

3.2. Is @OneToMany Lazy by Default?

Yes. Annotations that map a collection default to LAZY, and annotations that map a single entity default to EAGER.

Annotation	Default fetch type
@OneToMany	LAZY
@ManyToMany	LAZY
@ManyToOne	EAGER
@OneToOne	EAGER

We set fetch = FetchType.LAZY on every @ManyToOne, so loading a payment does not also load its account. We keep the collection LAZY too, because with EAGER, Hibernate loads all payments of every account it loads, even when we only need the owner name.

3.3. How Do I Fix the N+1 Select Problem?

The N+1 problem appears when we load N parents with one query and then read each parent’s lazy collection in a loop, because Hibernate runs one more query per parent. With three accounts, the loop runs 1 + 3 = 4 queries. For example, an admin page that lists 50 accounts with their payment totals runs 51 queries.

List<Account> accounts = em.createQuery("from Account", Account.class).getResultList();
// select a1_0.id,a1_0.owner from Account a1_0
accounts.forEach(a -> a.getPayments().size());
// select ... from Payment p1_0 where p1_0.account_id=? order by p1_0.amount desc   (3 times)

A join fetch query loads the accounts and their payments in one query. We use left join fetch so that accounts without payments are also returned.

List<Account> accounts = em.createQuery(
    "from Account a left join fetch a.payments", Account.class).getResultList();
// select a1_0.id,a1_0.owner,p1_0.account_id,p1_0.id,p1_0.amount,p1_0.description
//   from Account a1_0 left join Payment p1_0 on a1_0.id=p1_0.account_id order by p1_0.amount desc

Another fix is the hibernate.default_batch_fetch_size setting. It keeps the collections lazy, but loads the payments of up to 10 accounts with one IN query.

Approach	Queries for 3 accounts
Lazy collections read in a loop	4 (1 + N)
left join fetch a.payments	1
hibernate.default_batch_fetch_size = 10	2 (account_id in (?,?,…))

3.4. Why Do I Get a LazyInitializationException When Reading the Collection?

The collection was never loaded, and the transaction that loaded the account has ended, so Hibernate has no open session to run the query.

Account account = emf.callInTransaction(em -> em.find(Account.class, accountId));
int count = account.getPayments().size();   // LazyInitializationException

org.hibernate.LazyInitializationException: Cannot lazily initialize collection of role 'com.howtodoinjava.hibernate.onetomany.bidirectional.Account.payments' with key '1' (no session)

We load the payments while the transaction is still open.

• Fetch them in the query with left join fetch (see FAQ 3.3).
• Read the list inside the transaction, for example with getPayments().size().
• Call Hibernate.initialize() on the collection.

3.5. When Should I Use a Unidirectional One-to-Many?

Rarely, because both unidirectional forms run extra SQL (see section 1), and the bidirectional form costs only one field and two helper methods. Each option fits a different case.

• Bidirectional mappedBy with @ManyToOne is the default choice. It writes each row once, and we can go from an account to its payments and back.
• A @ManyToOne on the child without any collection fits an account with thousands of payments. We load them with a query such as select p from Payment p where p.account = :account, which also supports paging.
• A unidirectional @OneToMany with @JoinColumn is acceptable for small collections when the child class must not reference the parent.
• A unidirectional @OneToMany with a join table adds a table and rewrites it on every removal, so we avoid it for one-to-many.

4. Conclusion

A one-to-many mapping stores the relationship in one foreign key column of the child table. We map it with @OneToMany(mappedBy) on the parent and a lazy @ManyToOne on the child, and keep both sides in sync with helper methods. When we need the children of many parents, we use join fetch. The unidirectional forms work, but they run extra UPDATE statements or need a join table.

5. References

• Jakarta Persistence 3.2 specification: Bidirectional ManyToOne / OneToMany Relationships
• OneToMany JavaDoc (Jakarta Persistence 3.2)
• ManyToOne JavaDoc (Jakarta Persistence 3.2)
• OrderBy JavaDoc (Jakarta Persistence 3.2)
• Hibernate ORM 7.4 User Guide: @OneToMany
• Hibernate ORM 7.4 User Guide: Fetching

Happy Learning !!

Source Code on Github