Introduction

This Hibernate error usually means the entity uses a String primary key, but no generator is configured for that field. Hibernate knows how to auto-generate common numeric ids out of the box, but a plain String id is usually treated as application-assigned unless you explicitly define a generation strategy. So before calling save, the entity must already have a non-null id value.

Why Hibernate Says the ID Must Be Assigned

A typical entity looks like this:

1import jakarta.persistence.Entity;
2import jakarta.persistence.Id;
3
4@Entity
5public class Product {
6    @Id
7    private String id;
8
9    private String name;
10
11    // getters and setters omitted
12}

If you create a new Product and call save without setting id, Hibernate has no default way to invent a string primary key. That is why it throws the error.

Fix 1: Assign the String ID Yourself

If the application owns id generation, set the id before persisting.

1Product product = new Product();
2product.setId("prod-1001");
3product.setName("Keyboard");
4repository.save(product);

This is the simplest fix when ids come from a business rule, external system, slug, or UUID string generated by your own code.

A common pattern is to assign a UUID string in application code:

import java.util.UUID;

product.setId(UUID.randomUUID().toString());

Fix 2: Use a Numeric Generated ID Instead

If the id does not need to be a string, the easiest persistence model is often a generated numeric key.

1import jakarta.persistence.Entity;
2import jakarta.persistence.GeneratedValue;
3import jakarta.persistence.GenerationType;
4import jakarta.persistence.Id;
5
6@Entity
7public class Product {
8    @Id
9    @GeneratedValue(strategy = GenerationType.IDENTITY)
10    private Long id;
11
12    private String name;
13}

This removes the whole manual-assignment issue because Hibernate and the database can coordinate key generation automatically.

Fix 3: Keep String IDs but Generate Them in the Entity Lifecycle

If you want string ids everywhere but do not want to set them manually at every call site, generate them before persistence.

1import jakarta.persistence.Entity;
2import jakarta.persistence.Id;
3import jakarta.persistence.PrePersist;
4import java.util.UUID;
5
6@Entity
7public class Product {
8    @Id
9    private String id;
10
11    private String name;
12
13    @PrePersist
14    public void ensureId() {
15        if (id == null || id.isEmpty()) {
16            id = UUID.randomUUID().toString();
17        }
18    }
19}

This keeps the field as String while centralizing the generation rule.

Why This Often Appears with Spring Data save

Spring Data JPA's save does not change Hibernate's identifier rules. It still depends on the entity metadata. If the id field is application-assigned, save expects you to provide it before the insert happens.

So this is not really a Spring Data problem. It is an entity-mapping and identifier-generation problem that becomes visible when save triggers persistence.

Common Pitfalls

The biggest mistake is assuming that changing the id type from Long to String still preserves automatic generation behavior. Usually it does not unless you explicitly configure it.

Another issue is manually assigning string ids in some code paths but not others. That leads to inconsistent behavior where some inserts work and others fail with the same entity type.

People also sometimes use business-visible strings as primary keys without considering update risk. If the value can change, it may be a poor primary key even if it looks human-readable.

Finally, do not hide the problem by inserting blank strings. A non-null but meaningless id is still a bad identifier and can create harder database problems later.

Summary

• Hibernate usually treats a plain String @Id as manually assigned unless you configure generation.
• The error means the entity reached save with no usable id value.
• Fix it by assigning the string id yourself, generating it before persist, or switching to a generated numeric id.
• Spring Data save does not bypass Hibernate's identifier rules.
• Choose string primary keys intentionally, not just because they look convenient.