Spring Data JPA & Hibernate interview questions & answers

Teen naam aise use hote hain jaise ek hi cheez hon, aur interviewer ek minute me pata laga leta hai ki aap inhe alag kar paate hain ya nahi.

JPA ek specification hai. Wo @Entity jaisi annotations aur EntityManager jaise interfaces define karti hai, aur khud kuch implement nahi karti.

Hibernate us specification ka implementation hai - wo code jo asal me aapke objects ko SQL me badalta hai. Spring Boot me default yahi hai, aur isme spec se aage ke features bhi hain.

Spring Data JPA in dono ke upar ki layer hai. Isi ki wajah se aap bina implementation ke ek interface likhte hain aur aapko chalta hua repository mil jaata hai. Wo JPA ya Hibernate ki jagah nahi leta; wo unhe bulane wala boilerplate hatata hai.

Demo output ki ek line me ye poora stack dikha deta hai: repo bean class = $Proxy96. Aapne JobRepo ko interface ki tarah declare kiya aur koi class likhi hi nahi - Spring Data ne runtime par proxy bana diya, aur uske neeche Hibernate ne H2 par SQL chalayi.

ORM asal me kya hal karta hai

Java me objects hote hain jinme references hote hain; relational database me rows hoti hain jinme foreign keys hoti hain. In dono ke beech haath se aana-jaana matlab wahi shape ka code baar-baar likhna - ResultSet padho, column naam se nikaalo, object banao, aur save karne ke liye ye sab ulta karo. Ye yantrik kaam hai, aur har project ise thoda alag likhta hai.

ORM wahi mapping metadata se kar deta hai. @Entity, @Id aur field ke naam shape ek baar bata dete hain, aur baaki framework bana leta hai. Demo do rows save karta hai aur ek ko findByTitle naam ke method se wapas padhta hai - application me SQL kahin likhi hi nahi gayi.

Kab use karein: JPA tab lijiye jab aapki application ek domain model ke saath kaam karti ho - relationships wali entities, business ke niyam, aur ek lifecycle - aur database wahi jagah ho jahan wo model rakha jaata hai. Zyadatar business applications aisi hi hoti hain, isiliye Spring ki duniya me yahi default hai aur interviews ise maan kar chalte hain.

Kab NAHI use karein: imaandaar jawab ye hai ki ORM SQL ko chhupa deta hai, aur chhupi hui SQL me hi dikkatein rehti hain. Paanch tables par aggregate karne wali reporting query SQL me likhi jaye to zyada saaf aur aam taur par tez hoti hai - wahan JdbcTemplate ya native query sahi auzaar hai, JPQL se ladna nahi. Doosra case bulk operations ka hai: ek column badalne ke liye das lakh rows ko persistence context me laadna galat shape hai, aur ek UPDATE statement sahi. Mota niyam ye hai ki JPA us domain model ke liye hai jise aap chalate hain, bade data par set-based kaam ke liye nahi.

Yahi sauda is poore chapter ke naapne ki wajah hai. JPA ki lagbhag har performance dikkat jo aapko milegi - is chapter me aage aane wala N+1 uska classic roop hai - isi se aati hai ki aapko pata hi nahi hota ki aapke code ne kaunsi SQL chalwayi.

Do keemtein, milne se pehle jaan lijiye

Generated SQL dikhti hi nahi. Aapne koi query likhi hi nahi, to padhenge kya - aur jo statement asal me database tak pahunchi wo Java se bilkul alag ho sakti hai. Isi wajah se yahan performance ki dikkatein sahi-dikhte code ke andar chhup jaati hain, aur isi wajah se is chapter ka pehla hunar yahi hai ki generated SQL wapas chalu karke use gina jaye.

Portability asli hai, par adhoori. Hibernate ki jagah JPA ke against likhne ka matlab hai ki mapping aur JPQL implementations ke beech chalti rehti hain, aur database badalna zyadatar dialect ka badlaav rehta hai. Par Hibernate ke paas kuch kaam ke features hain jo specification me hain hi nahi, aur jis pal aap unme se koi use karte hain - koi Hibernate-khaas annotation, ya query me vendor ka function - us pal wo portability aapne de di. Imaandaar rukh ye hai ki default me JPA ka API chuniye aur vendor feature jaan-boojh kar uthaiye, uski keemat jaante hue - bina soche usme bahte mat jaiye.

// ---- smoke/Job.java ----
package smoke;

import jakarta.persistence.*;

@Entity
@Table(name = "job")
public class Job {
  @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;
  private String title;

  protected Job() { }                    // JPA ke liye zaroori
  public Job(String title) { this.title = title; }
  public Long getId() { return id; }
  public String getTitle() { return title; }
}

// ---- smoke/JobRepo.java ----
package smoke;

import org.springframework.data.jpa.repository.JpaRepository;
import java.util.List;

// DHYAN: repository interface TOP-LEVEL honi chahiye. Nested interface ko
// Spring Data ka scanner nahi uthata - ye is env me chala kar pakda gaya.
public interface JobRepo extends JpaRepository<Job, Long> {
  List<Job> findByTitle(String title);
}

// ---- smoke/Smoke.java ----
package smoke;

@SpringBootApplication
public class Smoke {
  public static void main(String[] args) {
    System.setProperty("spring.datasource.url", "jdbc:h2:mem:smoke;DB_CLOSE_DELAY=-1");
    System.setProperty("spring.jpa.hibernate.ddl-auto", "create-drop");
    try (ConfigurableApplicationContext ctx = SpringApplication.run(Smoke.class, args)) {
      JobRepo repo = ctx.getBean(JobRepo.class);
      repo.save(new Job("Java Developer"));
      repo.save(new Job("Backend Engineer"));
      List<Job> found = repo.findByTitle("Java Developer");
      System.out.println("  repo bean class = " + repo.getClass().getSimpleName());
      System.out.println("  saved rows      = " + repo.count());
      System.out.println("  derived query   = " + found.size() + " -> " + found.get(0).getTitle()
          + " (id=" + found.get(0).getId() + ")");
    }
  }
}

Entity ek aam Java class hai plus wo metadata jo batata hai ki wo row se kaise map hoti hai. Interviewer ka sawaal "annotations ginao" nahi hota - hota hai "in niyamon me se framework asal me kaunsa lagu karta hai, aur kab".

Jo niyam sach me zaroori hain

Teen cheezein: class par @Entity ho, ek @Id ho, aur ek no-arg constructor ho. Class final bhi nahi honi chahiye, aur persistent fields bhi final nahi - kyunki Hibernate ko subclass banakar reflection se instance bharna padta hai.

No-arg wala niyam chalane layak isliye hai ki uska waqt chaunkata hai. Demo me NoArgJob ke paas sirf (String) constructor hai. Application theek chal padi. save() bhi chal gaya. Phata pehli read par: org.hibernate.InstantiationException: No default constructor for entity. Poora sabak yahi hai - Hibernate ko constructor tab chahiye jab use row se object banana ho, isliye likhna pass ho jaata hai aur padhna toot-ta hai. Jo test sirf likhta hai, wo pass nikal jayega.

Constructor public hona zaroori nahi. protected Job() {} aam chunaav hai: JPA wahan tak pahunch jaata hai, aur application code galti se aadhi-khaali entity nahi bana paata.

Aap kuch na kahein to defaults kya karte hain

Demo ne Java par bharosa karne ki jagah H2 se uska apna information_schema poochha, aur jawab asli schema hai:

• @Table(name = "job_posting") ne table ka naam badla; iske bina table job hoti.
• @Column(name = "job_title", nullable = false, length = 120) se bana JOB_TITLE ... nullable=NO.
• postedCity par koi @Column nahi tha, phir bhi wo POSTED_CITY ban gaya - default naming strategy camelCase ko snake_case me badalti hai.
• @Embedded Salary ne doosri table nahi banayi. Uske fields usi row me MIN_LPA aur MAX_LPA ban gaye.
• @Transient displayLabel ka column hai hi nahi. Use set karke, save karke, context clear karke dobara load kiya to null mila.

nullable = false bhi sajawat nahi hai. Null title wali Job save karne par DataIntegrityViolationException aayi, aur root cause ne field ka naam le liya: PropertyValueException: not-null property references a null or transient value: mapdemo.Job.title. Dhyaan dijiye - ye Hibernate ne khud pakda, database tak baat pahunchne se pehle.

@GeneratedValue - strategy wala sawaal

IDENTITY database ke auto-increment column par tikta hai: id INSERT chalne ke baad hi pata chalti hai, isiliye iske neeche Hibernate inserts ko batch nahi kar paata. SEQUENCE database ke sequence object se chalta hai, to ids pehle se maangi ja sakti hain aur inserts batch ho sakte hain - PostgreSQL aur Oracle par yahi behtar default hai. AUTO faisla provider par chhod deta hai, aur TABLE ek extra table se sequence ki nakal karta hai aur ab lagbhag chalan se bahar hai.

Demo me dono lage. Output me hai IDENTITY ids = 1, 2 aur SEQUENCE ids = 1, 2, aur schema listing me sequences in schema = [COMPANY_SEQ] - SEQUENCE wali entity ke liye asli sequence object maujood hai aur IDENTITY wali ke liye koi nahi. Strategy ka naam usi object par hai.

Kab use karein: annotations se mapping tab kijiye jab class sach me aapke domain ka hissa ho aur database wahi jagah ho jahan wo rehti hai. Jin cheezon ki parwah hai unhe saaf likhiye - table ka naam, nullability, length, enum ka roop - aur baaki naming strategy par chhod dijiye, har field par haath se annotation thopne ki zaroorat nahi.

Kab NAHI karein: kisi aisi read-only shape ko entity mat banaiye jo sirf ek screen ya report ke liye chahiye. Projection ya DTO sasta padta hai aur apne peechhe persistence context nahi kheenchta. Aur @Enumerated(EnumType.ORDINAL) - jo STRING bhoolne par default lag jaata hai - saaf mana karne layak jaal hai: wo constant ki position store karta hai, to enum ka kram badalte hi purani rows ka matlab chupchaap badal jaata hai.

Ek H2 wali baat imaandaari se: output me status column ka type ENUM dikh raha hai, kyunki H2 me native enum type hai jise Hibernate 6 ne yahan use kar liya. PostgreSQL ya MySQL par aam taur par varchar dikhta. Padhne par value dono jagah String OPEN hi milti - annotation ki guarantee wahi hissa hai.

Kya entity me business logic rakhni chahiye?

Yahi "anemic domain model" wali bahas hai, aur ye tay ho chuka mamla nahi balki ek waajib interview sawaal hai. Anemic paksh kehta hai ki entities data rakhne ki cheez hain aur behaviour services me rahe; domain-model paksh kehta hai ki sirf getters-setters wali class kisi cheez ka model hai hi nahi.

Amli beech ka raasta ye hai: jo logic entity ki apni state ke baare me hai use entity par rakhiye - jaise ek method jo job posting band karke waqt darj kar de - aur jo logic kai entities ko jodta hai, doosri services bulata hai ya transaction kholta hai, wo service layer me. Parwah karne ki wajah shuddhata nahi hai: entity persistence context ke andar ek managed object hoti hai, to uspar kiya gaya koi bhi badlaav bina save bulaye UPDATE ban sakta hai - agla topic wahi naapta hai.

// ---- mapdemo/Job.java ----
@Entity
@Table(name = "job_posting")
public class Job {

  public enum Status { OPEN, CLOSED }

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

  @Column(name = "job_title", nullable = false, length = 120)
  private String title;

  private String postedCity;          // koi @Column nahi

  @Enumerated(EnumType.STRING)
  private Status status;

  @Embedded
  private Salary salary;              // minLpa, maxLpa

  @Transient
  private String displayLabel;        // kabhi store nahi hoga

  protected Job() {}                  // JPA ko yahi chahiye
  public Job(String title, String postedCity, Status status, Salary salary) { ... }
}

// ---- mapdemo/Company.java : doosri strategy ----
@Entity
public class Company {
  @Id
  @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "company_seq")
  @SequenceGenerator(name = "company_seq", sequenceName = "company_seq", allocationSize = 50)
  private Long id;
  private String name;
}

// ---- noargdemo/NoArgJob.java : jaan-boojh kar galat ----
@Entity
public class NoArgJob {
  @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id;
  private String title;
  public NoArgJob(String title) { this.title = title; }   // sirf yahi constructor
}

Ye chapter ka entry project hai. Ye jaan-boojh kar chhota hai - do entity, ek repository, ek service - kyunki baat job board ki nahi hai. Baat ye hai ki is chapter ke lagbhag saare faisle itni si persistence layer me dikh jaate hain, aur interviewer ek hi screen ke code se inme se kuch bhi poochh sakta hai.

Ye karta kya hai

Ek company jobs post karti hai. Jobs city se dhoondhi ja sakti hain, paging aur sorting ke saath, feed ki tarah dikhayi ja sakti hain, aur band ki ja sakti hain. Bas itna.

Isme kya-kya lagta hai, aur har cheez aayi kahan se

Mapping ke faisle, defaults nahi. @Table(name = "job_posting") aur @Column(name = "job_title", nullable = false, length = 140) likh kar diye gaye hain, naming strategy par chhode nahi, kyunki schema ek contract hai. Status @Enumerated(EnumType.STRING) hai - ORDINAL kabhi nahi. Ye topic 2 hai.

Soch-samajh kar chuna gaya fetch type. Job.company par @ManyToOne(fetch = FetchType.LAZY) EAGER default ko badalta hai. Iske bina har job list chupchaap har row ke liye ek company load karti. Ye topic 7 hai, ratta nahi - laga hua.

Jahan proxy kaafi hai wahan proxy. postJob ko company sirf foreign key set karne ke liye chahiye, isliye wo getReferenceById use karta hai - us row ke liye koi SELECT nahi jise koi padhta hi nahi. Ye topic 10 hai.

save() ki jagah dirty checking. closeJob job load karta hai, j.close() bulata hai, aur lautt jaata hai. Koi repository call nahi. Output se pakka hai ki row CLOSED aayi, aur search ka total 9 se 8 ho gaya kyunki band job nateejon se nikal gayi. Ye topic 9 hai.

Behaviour entity par. close() Job par hai, service me nahi, kyunki job ka apna status badalna job ka hi kaam hai. Talmel service me rehta hai. Ye topic 2 wali anemic-model lakeer hai, ek thos jagah par kheenchi hui.

Jahan total chahiye wahan Page, jahan nahi wahan Slice. Search Page lautata hai aur 2 queries lagayi, totalElements ke saath; feed Slice lautata hai aur 1 lagayi. Wahi data, alag screen, alag daam. Ye topic 12 hai.

Transaction ki seema service par. Har public method par @Transactional hai, aur jahan sirf padhna hai wahan read-only. Repository par kuch nahi. Ye phir topic 9 hai, aur bolne me sabse zyada log yahi galat karte hain.

Is shakl me kab banaiye: jab dilchasp hissa persistence layer ho - jo ki zyadatar CRUD jaisa backend kaam hota hai. Ye shakl badhti bhi hai: entities apni state ki maalik, service operation ka naam aur transaction ki maalik, aur repository sirf queries ka sangrah.

Kab NAHI use karein: jab kaam sach me set-based ho tab ye shakl mat uthaiye. Das lakh rows par aggregate karne wali maheene ki report ko entities banana hi nahi chahiye; wahan projection ya saadi SQL sahi auzaar hai, aur ye project jaan-boojh kar aisa dikhaava nahi karta.

Jo imaandaari se yahan nahi hai

Yahan koi HTTP layer nahi hai. Is chapter ka environment spring.main.web-application-type=none par chalta hai, aur REST wala aadha hissa - @RestController, ResponseEntity, validation, ProblemDetail - Ch8 me pehle hi ban aur naapa ja chuka hai. Dono aadhe maujood hon to is service ke upar controller lagana yantrik kaam hai, aur persistence wala hissa hi is chapter ki zimmedari hai. Service ke methods wahi jod hain jahan wo controller judega.

// ---- proj16/Job.java ----
@Entity
@Table(name = "job_posting")
public class Job {
  @Column(name = "job_title", nullable = false, length = 140) private String title;
  @Enumerated(EnumType.STRING) private Status status = Status.OPEN;

  @ManyToOne(fetch = FetchType.LAZY)          // topic 7 ka faisla
  @JoinColumn(name = "company_id") private Company company;

  public void close() { this.status = Status.CLOSED; }   // entity apni state ki maalik
}

// ---- proj16/JobRepo.java ----
Page<Job>  findByStatusAndCityIgnoreCase(Job.Status status, String city, Pageable pageable);
Slice<Job> findByStatus(Job.Status status, Pageable pageable);

// ---- proj16/JobService.java : transaction ki seema YAHAN ----
@Transactional
public Long postJob(Long companyId, String title, String city, int salary) {
  Company c = companies.getReferenceById(companyId);     // FK ke liye proxy kaafi
  Job j = new Job(title, city, salary);
  j.setCompany(c);
  return jobs.save(j).getId();
}

@Transactional
public void closeJob(Long jobId) {
  Job j = jobs.findById(jobId).orElseThrow();
  j.close();                                              // koi save() nahi
}