---

1. Hibernate DDL Auto Configuration

spring.jpa.hibernate.ddl-auto

This property tells Hibernate how to handle DB schema.

Value	Create	Update	Delete	Use case
none	❌	❌	❌	Does nothing – Best for Production
update	✅	✅	❌	Updates schema without deleting data – Good for Dev
validate	❌	❌	❌	Only validates schema, throws error if mismatch
create	✅	✅	✅	Drops & recreates tables on startup
create-drop	✅	✅	✅	Drops on shutdown – Default for H2/in-memory DB

Extra tip

Never use create or create-drop in production. One restart = data gone.

---

2. Mapping Class to Table – @Table

@Table is optional.

If not used:

@Entity
public class UserDetails {}

Table becomes → USER_DETAILS (CamelCase → UPPER_SNAKE_CASE)

With @Table

@Table(name="USER_DETAILS", schema="ONBOARDING")
@Entity
public class UserDetails {}

---

3. Unique Constraints & Indexes

@Table(
  name="USER_DETAILS",
  uniqueConstraints={
     @UniqueConstraint(columnNames="phone"),
     @UniqueConstraint(columnNames={"name","email"})
  },
  indexes={
     @Index(name="idx_phone", columnList="phone"),
     @Index(name="idx_name_email", columnList="name,email")
  }
)

Meaning

• phone → single column unique
• name+email → composite unique
• Index improves search performance

---

4. Column Mapping – @Column

Optional annotation.

@Column(
  name="FULL_NAME",
  unique=true,
  nullable=false,
  length=20
)
private String name;

Controls:

• Column name
• Nullability
• Length
• Uniqueness

---

5. Primary Key – @Id

Rules:

• Must be unique & not null
• Only one @Id per entity
• Every entity must have one

---

6. Composite Primary Key

Two approaches:

A) Using @IdClass

@IdClass(UserDetailsCK.class)
@Entity
public class UserDetails {
   @Id private String name;
   @Id private String address;
}

Key class must:

• be public
• implement Serializable
• have no-arg constructor
• override equals & hashCode

B) Using @EmbeddedId

@EmbeddedId
private UserDetailsCK id;

---

Why equals() & hashCode() needed?

Because Hibernate caching uses HashMap internally.
Without proper keys → cache breaks.

---

Why Serializable needed?

Composite keys may travel across network in distributed cache.

---

7. ID Generation Strategies

1. IDENTITY

@GeneratedValue(strategy = GenerationType.IDENTITY)

• Auto-increment by DB
• Simple but DB dependent
• No caching

---

2. SEQUENCE (Best for Enterprise)

@SequenceGenerator(
  name="user_seq",
  sequenceName="user_seq",
  initialValue=100,
  allocationSize=5
)
@GeneratedValue(strategy=GenerationType.SEQUENCE, generator="user_seq")

How allocationSize works

Hibernate fetches 5 IDs at once:

• Avoids hitting DB every insert
• Huge performance gain

---

3. TABLE

Uses a separate table to generate IDs
❌ Slow
❌ Locking issues
❌ Avoid in real systems

---

Why SEQUENCE is better than IDENTITY

Feature	SEQUENCE	IDENTITY
Caching	✅ Yes	❌ No
DB calls	Low	High
Multi-table	Yes	No
Portability	High	Low
Performance	⭐⭐⭐⭐	⭐⭐

---

REAL WORLD BEST PRACTICES (Extra)

Scenario	Recommended
Production DB	SEQUENCE
Small project	IDENTITY
In-memory DB	create-drop
Microservices	SEQUENCE + UUID
Bulk inserts	SEQUENCE

---

Interview Questions & Answers

Q1. Difference between validate and update?

• validate → only checks schema
• update → modifies schema

---

Q2. Can we have multiple @Id?

No. Use composite key instead.

---

Q3. Which is fastest ID strategy?

SEQUENCE with allocationSize > 1

---

Q4. Why not TABLE strategy?

Because it uses:

• extra table
• locking
• multiple DB hits

---

Q5. What happens if equals/hashCode is wrong?

Hibernate cache will:

• return wrong data
• create duplicates
• cause memory leaks

---

Q6. Can @Column be skipped?

Yes, JPA generates default columns automatically.

---

Q7. Best ddl-auto value for production?

none or validate

---

Q8. Difference between UniqueConstraint and Index?

• Unique → enforces data rule
• Index → improves performance only

---

One-liner for Interviews (You can memorize)

“In production we should always use SEQUENCE for ID generation and never use create or create-drop for schema management.”