Spring Data JPA আর Hibernate — entity, relationship আর transaction

১ · তিন স্তর — JPA, Hibernate আর Spring Data JPA

পর্ব ৪৯-এ JDBC দিয়ে হাতে SQL লিখেছেন: PreparedStatement বানানো, প্রতিটি parameter বসানো, ResultSet থেকে এক এক করে কলাম পড়ে object বানানো। দশটি টেবিলের একটি অনলাইন দোকানে এই কাজ শত শত লাইনের একঘেয়ে কোড। পর্ব ৫১-এ দেখেছেন, Spring Data JPA-তে শুধু একটি interface লিখলেই findById, save চলে আসে। এই পর্বে সেই জাদুর ভেতরে ঢুকব। কারণ একটি সহজ সত্য: প্রতিটি সুবিধা কিছু SQL লুকিয়ে রাখে। পেশাদার ডেভেলপারকে জানতে হয় কোন SQL চলছে, কখন চলছে, আর কোন transaction-এর ভেতরে।

এখানে তিনটি আলাদা জিনিস একসাথে কাজ করে, আর নামগুলো প্রায়ই গুলিয়ে যায়:

একটি ছোট ধাপে তিন স্তর দেখুন। নিচের তিনটি লাইন একই কাজ করে — ৭ নম্বর পণ্য আনা:

// ১. JDBC (পর্ব ৪৯) — সব হাতে
ps = con.prepareStatement("select id, name, price, stock from product where id = ?");
ps.setLong(1, 7);  rs = ps.executeQuery();  /* তারপর rs থেকে new Product(...) */

// ২. JPA-র EntityManager — SQL বানায় Hibernate
Product p = em.find(Product.class, 7L);

// ৩. Spring Data JPA — interface-এর method, বাস্তবায়ন চলার সময় তৈরি
Optional<Product> p = productRepository.findById(7L);

তিন নম্বরের ভেতরে আসলে দুই নম্বরই চলে, আর দুই নম্বরের ভেতরে এক নম্বর। স্তর যত ওপরে, কোড তত ছোট — আর লুকোনো আচরণ তত বেশি। এই পর্বের Spring কোড Spring Boot 3.x আর Hibernate 6.x ধরে লেখা (package jakarta.persistence); পরের বড় সংস্করণে কিছু খুঁটিনাটি বদলাতে পারে, ধারণাগুলো একই থাকে। এসব লাইব্রেরি অনলাইন runner-এ নেই, তাই Spring/JPA কোড চালানো যাবে না — পাশে প্রত্যাশিত ফল লেখা আছে। আর দুটি চালানো যায় এমন উদাহরণে আমরা সাধারণ Java দিয়েই Hibernate-এর মূল কৌশল দুটি নিজেরা বানিয়ে দেখব।

২ · entity mapping — টেবিলের সাথে class মেলানো

আমাদের উদাহরণ একটি অনলাইন দোকান, যেখানে নানা জেলার পণ্য বিক্রি হয় — রাজশাহীর আম, বগুড়ার দই, সিলেটের চা-পাতা। চারটি entity: Customer, Order, OrderItem আর Product. প্রথমে Product:

@Entity
@Table(name = "product")
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "product_seq")
    @SequenceGenerator(name = "product_seq", sequenceName = "product_seq", allocationSize = 50)
    private Long id;

    @Column(nullable = false, unique = true, length = 40) private String sku;      // পণ্যের কোড
    @Column(nullable = false, length = 120)              private String name;
    @Column(nullable = false, length = 40)               private String district;  // উৎস জেলা
    @Column(nullable = false, precision = 12, scale = 2) private BigDecimal price;
    private int stock;

    @Enumerated(EnumType.STRING) @Column(nullable = false, length = 20)
    private ProductStatus status = ProductStatus.ACTIVE;

    @Version private long version;                     // অংশ ৭-এ — দুজনের একসাথে বদল ধরতে

    protected Product() {}                             // JPA-র জন্য খালি constructor
    public Product(String sku, String name, String district, BigDecimal price, int stock) { ... }
    // getter, আর শুধু যেগুলো বদলানোর কথা সেগুলোর setter …
}

id কে বানাবে — IDENTITY না SEQUENCE

GenerationType.IDENTITY মানে ডেটাবেসের auto-increment কলাম (MySQL-এর AUTO_INCREMENT, PostgreSQL-এর identity কলাম)। সহজ, কিন্তু একটি দাম আছে: id জানা যায় শুধু INSERT চালানোর পর। তাই Hibernate persist()-এর সাথে সাথেই INSERT চালাতে বাধ্য, আর অনেকগুলো INSERT একসাথে batch করে পাঠাতে পারে না। GenerationType.SEQUENCE-এ ডেটাবেসের একটি আলাদা sequence থেকে id আসে। allocationSize = 50 দিলে Hibernate একবারে ৫০টি id-এর একটি খণ্ড নেয়, তারপর মেমরি থেকেই বিলি করে — ৫০টি নতুন পণ্যে sequence-এ মাত্র এক-দুবার যাওয়া, আর INSERT-গুলো batch করা যায়। PostgreSQL বা Oracle-এ SEQUENCE ভালো পছন্দ; MySQL-এ sequence নেই, সেখানে IDENTITY-ই প্রচলিত।

enum — কেন ORDINAL নয়

পর্ব ২৪-এ দেখেছেন, প্রতিটি enum constant-এর একটি ক্রমিক সংখ্যা আছে (ordinal())। @Enumerated না লিখলে JPA এই সংখ্যাটিই টেবিলে রাখে: ACTIVE = 0, DISCONTINUED = 1. এক বছর পর কেউ মাঝখানে OUT_OF_SEASON যোগ করলেন — এখন DISCONTINUED হয়ে গেল 2. কিন্তু টেবিলে আগের হাজার সারিতে লেখা 1, যা এখন পড়া হবে OUT_OF_SEASON হিসেবে। কোনো error নেই, শুধু নীরবে ভুল ডেটা। EnumType.STRING নাম লেখে, তাই ক্রম বদলালে কিছু ভাঙে না (নাম বদলালে অবশ্য migration লাগবে)।

embeddable — ঠিকানা আর টাকার মতো value object

অর্ডারের ডেলিভারি ঠিকানায় থাকে জেলা, এলাকা আর বাড়ির লাইন। এগুলোর আলাদা পরিচয় নেই — দুটি ঠিকানার সব ঘর মিললে তারা একই ঠিকানা; এটাই value object. এর জন্য আলাদা টেবিল লাগে না; @Embeddable class বানিয়ে entity-তে @Embedded লিখলে তার field-গুলো মালিক entity-র টেবিলেই কলাম হয়ে যায়:

@Embeddable
public class Address {
    @Column(nullable = false, length = 40) private String district;   // orders.district কলাম
    @Column(nullable = false, length = 80) private String area;
    private String line;
    protected Address() {}
    public Address(String district, String area, String line) { ... }
}
// Order-এর ভেতরে:   @Embedded private Address deliveryAddress;

Java-তে কোডের ভাষায় order.getDeliveryAddress().getDistrict() — পরিষ্কার একটি ধারণা; আর টেবিলে সাধারণ কলাম। টাকার পরিমাণ আর মুদ্রা মিলিয়ে একটি Money বানানোও একই কৌশল। নতুন সংস্করণে (Hibernate 6.2 আর Jakarta Persistence 3.2 থেকে) record-ও embeddable হিসেবে চলে বলে ডকুমেন্টে আছে; ব্যবহারের আগে নিজের সংস্করণে মিলিয়ে নিন।

৩ · persistence context — entity-র জীবনচক্র আর dirty checking

Hibernate-এর সবচেয়ে গুরুত্বপূর্ণ — আর সবচেয়ে কম বোঝা — ধারণা হলো persistence context. সাধারণত প্রতিটি transaction-এর সাথে একটি করে। এটা একটি খাতা, যেখানে লেখা থাকে এই transaction-এ কোন কোন entity আনা হয়েছে, আর আনার মুহূর্তে প্রতিটির মান কী ছিল। এর দুটি কাজ:

• এক id, এক object: একই transaction-এ find(Product.class, 1L) দুবার ডাকলে দ্বিতীয়বার SQL যায় না, একই Java object ফেরত আসে। এর নাম first-level cache বা identity map. তাই এখানে == সত্য হয় — কিন্তু শুধু এই context-এর ভেতরে।
• নিজে থেকে বদল খোঁজা: commit-এর আগে Hibernate প্রতিটি entity-র বর্তমান মান আনার সময়ের কপির (snapshot) সাথে মেলায়। যেটা বদলেছে, তার জন্য UPDATE চালায়। এর নাম dirty checking. তাই @Transactional method-এ product.setStock(47) লিখলেই যথেষ্ট — save() লাগে না।

জমে থাকা বদল SQL হয়ে ডেটাবেসে পাঠানোর নাম flush. flush মানে commit নয় — SQL গেল, কিন্তু transaction এখনো খোলা, ROLLBACK হলে সব বাতিল। ডিফল্টে flush হয় commit-এর ঠিক আগে, আর এমন query চালানোর আগে যার ফল জমে থাকা বদলের ওপর নির্ভর করতে পারে (যাতে query পুরোনো ডেটা না দেখে)। em.flush() দিয়ে নিজেও আগে পাঠানো যায়।

প্রতিটি entity object এই খাতার সাপেক্ষে চারটি অবস্থার একটিতে থাকে — এটাই entity-র জীবনচক্র. ধাপে ধাপে দেখুন:

Product p = new Product("DOI-1", "বগুড়ার দই", "Bogura", 300, 20);
p.getId() → null
সাধারণ Java object — Hibernate একে চেনেই না

em.persist(p);
খাতা: Product#51 → p   snapshot {stock=20, ...}
SEQUENCE থেকে id এলো; INSERT এখনো জমা আছে

p.setStock(18);
বর্তমান {stock=18}  ≠  snapshot {stock=20}
কোনো SQL যায়নি — শুধু মেমরিতে বদল

insert into product (district, name, price, sku, status, stock, version, id)
       values (?, ?, ?, ?, ?, ?, ?, ?)
একই transaction-এ নতুন আর বদলানো — Hibernate মিলিয়ে
INSERT-এ সরাসরি stock=18 পাঠাল (আলাদা UPDATE লাগেনি)

COMMIT
এখন অন্য connection-ও নতুন দই দেখতে পাবে

p.setStock(5);        // transaction-এর বাইরে
কোনো SQL কখনো যাবে না
p.getOrders()...      // lazy সম্পর্ক → LazyInitializationException
Product fresh = em.merge(p);   // নতুন transaction-এ আবার যুক্ত করা

লক্ষ করুন, save() ভেতরে দেখে entity নতুন কি না — নতুন হলে persist, না হলে merge. আর save()-এর ফেরত মানটিই ব্যবহার করুন: merge-এর ক্ষেত্রে সেটা আলাদা object হতে পারে। এবার Hibernate-এর এই দুটি কৌশল — identity map আর dirty checking — সাধারণ Java দিয়ে নিজেরাই বানিয়ে দেখুন। ডেটাবেসের বদলে একটি Map, আর SQL চালানোর বদলে SQL-টি ছাপানো:

import java.util.*;

class Product {
    final long id; String name; int stock;
    Product(long id, String name, int stock) { this.id = id; this.name = name; this.stock = stock; }
}
class PersistenceContext {                                   // Hibernate Session-এর খুব ছোট নকল
    private final Map<Long, Product> managed = new TreeMap<>();         // identity map
    private final Map<Long, List<Object>> snapshot = new TreeMap<>();   // লোডের সময়ের কপি
    private final Map<Long, String> db = Map.of(1L, "Tea,50", 2L, "Rice,20");   // "টেবিল"
    Product find(long id) {
        if (managed.containsKey(id)) { System.out.println("find(" + id + ") -> cache, no SQL"); return managed.get(id); }
        System.out.println("SQL: select * from product where id=" + id);
        String[] row = db.get(id).split(",");
        var p = new Product(id, row[0], Integer.parseInt(row[1]));
        managed.put(id, p); snapshot.put(id, List.of(p.name, p.stock));
        return p;
    }
    void flush() {                                           // dirty checking
        for (Product p : managed.values())
            if (!List.of(p.name, p.stock).equals(snapshot.get(p.id))) {
                System.out.println("SQL: update product set name='" + p.name + "', stock=" + p.stock + " where id=" + p.id);
                snapshot.put(p.id, List.of(p.name, p.stock));
            }
        System.out.println("flush done");
    }
}
class Main {
    public static void main(String[] args) {
        var em = new PersistenceContext();
        Product tea = em.find(1);
        em.find(2);
        System.out.println("same object? " + (tea == em.find(1)));
        tea.stock -= 3;                                       // কোনো save() নেই
        em.flush();
        em.flush();                                           // আর কিছু বদলায়নি
    }
}

৪ · relationship — একজন গ্রাহক, অনেক অর্ডার

টেবিলে সম্পর্ক থাকে একটি foreign key কলামে: orders.customer_id বলে অর্ডারটি কার। Java-তে সম্পর্ক থাকে reference-এ: order.getCustomer(), আর উল্টো দিকে customer.getOrders(). সমস্যা হলো, Java-তে দুটি আলাদা reference, কিন্তু টেবিলে একটিই কলাম। কোন reference সেই কলামের “মালিক”, তা JPA-কে বলে দিতে হয়।

@Entity
@Table(name = "orders")
public class Order {
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) private Long id;

    @ManyToOne(fetch = FetchType.LAZY, optional = false)      // owning side: foreign key এখানে
    @JoinColumn(name = "customer_id")
    private Customer customer;

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItem> items = new ArrayList<>();     // inverse side

    @Embedded private Address deliveryAddress;
    @Enumerated(EnumType.STRING) private OrderStatus status = OrderStatus.PLACED;
    private Instant placedAt = Instant.now();

    public void addItem(OrderItem item)    { items.add(item);    item.setOrder(this); }   // দুই দিক একসাথে
    public void removeItem(OrderItem item) { items.remove(item); item.setOrder(null); }
}

@Entity
public class OrderItem {
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE) private Long id;
    @ManyToOne(fetch = FetchType.LAZY, optional = false) private Order order;     // order_id
    @ManyToOne(fetch = FetchType.LAZY, optional = false) private Product product; // product_id
    private int quantity;
    @Column(precision = 12, scale = 2) private BigDecimal unitPrice;   // কেনার মুহূর্তের দাম
}

• @ManyToOne = owning side. অনেক অর্ডার, একজন গ্রাহক। foreign key এই টেবিলে, তাই Hibernate UPDATE বা INSERT-এ customer_id কী লিখবে, তা ঠিক করে শুধু এই field দেখে।
• @OneToMany(mappedBy = "order") = inverse side. mappedBy বলে “এই সম্পর্কের আসল মালিক OrderItem.order field”. শুধু order.getItems().add(item) লিখে item.setOrder(order) না লিখলে টেবিলে order_id বসবেই না — Hibernate inverse দিক দেখে কলাম লেখে না।
• helper method. তাই addItem/removeItem দুই দিক একসাথে মেলায়। এটা না থাকলে মেমরির object-গুলো আর টেবিল একে অপরের সাথে অমিল হয়ে যায় — এমন বাগ খুঁজে পাওয়া কঠিন। unitPrice আলাদা রাখার কারণ: পণ্যের দাম পরে বদলালেও পুরোনো অর্ডারের দাম বদলাবে না।

@ManyToMany — আর কেন প্রায়ই আলাদা join entity ভালো

একটি পণ্য অনেক ক্যাটাগরিতে (“ফল”, “মৌসুমি”), একটি ক্যাটাগরিতে অনেক পণ্য। টেবিলে এর জন্য তৃতীয় একটি join table লাগে: product_category(product_id, category_id). JPA-তে @ManyToMany আর @JoinTable লিখলে Hibernate এই টেবিল নিজে সামলায়। কিন্তু দুটি কারণে অভিজ্ঞ দল প্রায়ই ProductCategory নামে একটি আলাদা entity বানায়, দুটি @ManyToOne-সহ। প্রথমত, সম্পর্কের নিজের তথ্য প্রায় সবসময় পরে আসে — কবে যোগ হলো, তালিকায় কোন ক্রমে দেখাবে। join table-এ নতুন কলাম রাখার জায়গা @ManyToMany-তে নেই। দ্বিতীয়ত, List দিয়ে @ManyToMany করলে Hibernate একটি সারি সরাতে গিয়ে অনেক সময় সেই পণ্যের সব সারি মুছে আবার ঢোকায়; অন্তত Set ব্যবহার করুন।

cascade আর orphanRemoval

cascade মানে মালিক entity-র ওপর করা কাজ সম্পর্কিত entity-তেও ছড়িয়ে দেওয়া। CascadeType.PERSIST: অর্ডার persist করলে নতুন আইটেমগুলোও; REMOVE: অর্ডার মুছলে আইটেমগুলোও; ALL: সবগুলো। আর orphanRemoval মানে সংগ্রহ থেকে সরিয়ে দেওয়া সন্তান entity মুছে ফেলা — অর্ডার ছাড়া একটি আইটেমের কোনো অর্থ নেই। ধাপে ধাপে দেখুন:

Order order = orderRepo.findById(9L).orElseThrow();   // managed
order.addItem(new OrderItem(mango, 2, price));         // নতুন = transient
item.order = order   আর   order.items-এ item

insert into order_item (order_id, product_id, quantity, unit_price, id)
       values (9, 3, 2, 650.00, ?)
item-এর জন্য আলাদা save() ডাকতে হয়নি

order.removeItem(item);
order.items থেকে বাদ,  item.order = null
item এখন “এতিম” — কোনো অর্ডারের নয়

delete from order_item where id=?
সংগ্রহ থেকে সরানো মানেই মুছে ফেলা

update order_item set order_id=null ... where id=?
order_id NOT NULL → constraint violation
নয়তো টেবিলে মালিকহীন সারি জমে থাকে

OrderItem:  @ManyToOne(cascade = CascadeType.REMOVE) Product product;
orderItemRepo.delete(item);
delete from product where id=3   ← রাজশাহীর আম-ই উধাও!

৫ · LAZY, EAGER আর N+1 সমস্যা

একটি অর্ডার আনলে তার গ্রাহক, আইটেম, প্রতিটি আইটেমের পণ্য — সব কি একসাথে আনা উচিত? সব আনলে একটি সাধারণ তালিকার পাতায় পুরো ডেটাবেস টেনে আনার ঝুঁকি। তাই JPA-তে প্রতিটি সম্পর্কের একটি fetch type আছে। LAZY মানে দরকার না পড়া পর্যন্ত আনা হবে না: Hibernate আসল Customer-এর জায়গায় একটি proxy বসায় (পর্ব ৪৮-এর proxy pattern), যার কোনো field প্রথমবার ছুঁলে তবেই SELECT যায়। EAGER মানে মালিক আনার সাথে সাথেই আনা।

এই অসমতা JPA 1.0-র একটি পুরোনো সিদ্ধান্ত, আর বেশিরভাগ বিশেষজ্ঞ এটাকে দুর্ভাগ্যজনক মনে করেন। EAGER ভালো শোনায় — “সব হাতের কাছে” — কিন্তু তা বদলানো যায় না: যে পাতায় গ্রাহকের দরকার নেই, সেখানেও গ্রাহক আসবে, আর গ্রাহকের EAGER সম্পর্কও, এভাবে শিকলের মতো। উল্টোটা সহজ: সব LAZY রাখুন, আর যে query-তে দরকার, শুধু সেখানে একসাথে আনুন।

LazyInitializationException — খাতা বন্ধ হওয়ার পর proxy ছোঁয়া

LAZY proxy নিজের ডেটা আনতে খোলা persistence context লাগে। transaction শেষ হওয়ার পর — ধরুন controller-এ, বা JSON বানানোর সময় — order.getCustomer().getName() ডাকলে Hibernate SELECT চালানোর জায়গা পায় না:

org.hibernate.LazyInitializationException: could not initialize proxy [com.shop.Customer#10] - no Session

সংগ্রহের ক্ষেত্রে বার্তাটি মোটামুটি “failed to lazily initialize a collection of role: com.shop.Order.items … no Session”. হুবহু লেখা সংস্করণভেদে আলাদা; মূল কথা “no Session” — খাতা বন্ধ। ভুল সমাধান হলো সম্পর্কটি EAGER করে দেওয়া। সঠিক সমাধান: service-এর transaction-এর ভেতরেই দরকারি ডেটা একসাথে এনে DTO বানিয়ে ফেরত দেওয়া।

N+1 — লুপের ভেতরে লুকোনো query

পর্ব ৪৯-এ হাতে লেখা JDBC-তে আর পর্ব ৫১-এ এক ঝলক দেখেছেন N+1 সমস্যা. ORM-এ এটা সবচেয়ে বেশি দেখা যায়, কারণ o.getCustomer().getName() দেখতে একটি নিরীহ getter. নিচের stepper-এ তিনটি অর্ডারের তালিকা ছাপাতে কয়টি SQL যায়, গুনে দেখুন:

1@Transactional(readOnly = true)2List<Order> orders = orderRepo.findAll();3for (Order o : orders)4  print(o.getId() + " " + o.getCustomer().getName());5// ---- একই কাজ, একটি query-তে ----6@Query("select o from Order o join fetch o.customer")7List<Order> findAllWithCustomer();8for (Order o : orderRepo.findAllWithCustomer()) print(...);

একই ঘটনা সাধারণ Java দিয়ে চালিয়ে দেখুন। এখানে Order.getCustomer() একটি সাধারণ getter-এর মতো দেখতে, কিন্তু ভেতরে Hibernate-এর lazy proxy-র মতো প্রথম ডাকে একটি “query” চালায়। একই লুপ দুইভাবে চলে — lazy আর join fetch:

import java.util.*;
import java.util.function.Supplier;

class Order {
    final long id; private final Supplier<String> loader; private String customer;
    Order(long id, Supplier<String> loader) { this.id = id; this.loader = loader; }
    String getCustomer() { if (customer == null) customer = loader.get(); return customer; }   // দেখতে সাধারণ getter
}
class Db {
    int queries;
    private final Map<Long, String> customers = Map.of(10L, "Rahim", 11L, "Karim", 12L, "Shila");
    private final long[][] orders = {{1, 10}, {2, 11}, {3, 12}};                    // {order id, customer id}
    private void sql(String s) { queries++; System.out.println("  SQL #" + queries + ": " + s); }
    List<Order> findAll(boolean joinFetch) {
        sql(joinFetch ? "select o.*, c.* from orders o join customer c on c.id=o.customer_id" : "select * from orders");
        var list = new ArrayList<Order>();
        for (long[] o : orders) {
            String name = customers.get(o[1]);
            list.add(new Order(o[0], joinFetch ? () -> name
                    : () -> { sql("select * from customer where id=" + o[1]); return name; }));
        }
        return list;
    }
}
class Main {
    public static void main(String[] args) {
        for (boolean fetch : new boolean[] {false, true}) {
            var db = new Db();
            System.out.println(fetch ? "JOIN FETCH:" : "LAZY:");
            for (Order o : db.findAll(fetch)) System.out.println("  order " + o.id + " -> " + o.getCustomer());
            System.out.println("  total queries = " + db.queries);
        }
    }
}

তিনটি প্রতিকার

public interface OrderRepository extends JpaRepository<Order, Long> {

    // ১. JPQL-এ join fetch
    @Query("select o from Order o join fetch o.customer where o.status = :status")
    List<Order> findWithCustomer(@Param("status") OrderStatus status);

    // ২. @EntityGraph — query একই, শুধু বলে দেওয়া কোন সম্পর্ক একসাথে আনতে হবে
    @EntityGraph(attributePaths = {"customer", "items"})
    Optional<Order> findWithItemsById(Long id);
}

# ৩. batch fetching — lazy proxy বা সংগ্রহ একটি একটি না এনে একবারে অনেকগুলো
spring.jpa.properties.hibernate.default_batch_fetch_size=16

join fetch সবচেয়ে সরাসরি: একটি SQL. @EntityGraph একই কাজ annotation দিয়ে করে, derived query-র সাথেও চলে। আর batch fetching একটি নিরাপত্তা-জাল: lazy proxy ছোঁয়া হলে Hibernate একসাথে ১৬টি পর্যন্ত id-এর জন্য where id in (?, ?, …) চালায় — ১০০০ অর্ডারে ১০০১টির বদলে মোটামুটি ১ + ৬৩টি query. কোড না বদলেই বড় উন্নতি, তাই অনেক দল এটা ডিফল্ট হিসেবে চালু রাখে।

৬ · Spring Data repository — derived query, JPQL, projection আর pagination

পর্ব ৫১-এ derived query-র প্রথম রূপ দেখেছেন। নামের ব্যাকরণ আরও অনেক দূর যায়: find…By, exists…By, count…By, delete…By, তারপর field-এর নাম আর And, Or, LessThan, Between, Containing, IgnoreCase, OrderBy…Desc-এর মতো শব্দ।

public interface ProductRepository extends JpaRepository<Product, Long> {

    Page<Product> findByDistrictAndPriceLessThan(String district, BigDecimal max, Pageable pageable);
    boolean existsBySku(String sku);                       // select ... limit 1 — পুরো সারি আনে না
    long countByStockLessThan(int threshold);              // কম স্টকের পণ্য কয়টি

    @Query("select p from Product p where lower(p.name) like lower(concat('%', :q, '%'))")
    List<Product> search(@Param("q") String q);           // JPQL — টেবিল নয়, entity আর field-এর নাম

    @Query(value = "select * from product where stock = 0 and status = 'ACTIVE'", nativeQuery = true)
    List<Product> outOfStockNative();                     // native SQL — ডেটাবেসের নিজের ভাষা

    @Modifying(clearAutomatically = true)
    @Query("update Product p set p.price = p.price * :factor where p.district = :district")
    int reprice(@Param("district") String district, @Param("factor") BigDecimal factor);
}

• নামের সীমা। findByDistrictAndPriceLessThanAndStatusAndStockGreaterThanOrderByPriceAsc কাজ করবে, কিন্তু কেউ পড়তে পারবে না। দুই-তিনটি শর্তের বেশি হলে @Query লিখুন। নামে বানান ভুল হলে অ্যাপ চালুর সময়েই error — এটা ভালো দিক।
• JPQL বনাম native query. JPQL entity আর field-এর নাম ব্যবহার করে, Hibernate তা ডেটাবেস অনুযায়ী SQL-এ বদলায় — ডেটাবেস বদলালেও চলে। native query ডেটাবেসের নিজস্ব সুবিধা (window function, PostgreSQL-এর JSON অপারেটর) দেয়, কিন্তু সেই ডেটাবেসে বাঁধা।
• @Modifying. বাল্ক UPDATE বা DELETE সরাসরি ডেটাবেসে যায়, persistence context-কে পাশ কাটিয়ে। খাতায় আগে থেকে থাকা Product object-গুলো তখন পুরোনো দাম দেখায় — তাই clearAutomatically = true. এছাড়া বাল্ক query @Version বাড়ায় না আর entity-র lifecycle callback চালায় না। transaction লাগবে (অংশ ৭)।

pagination — পণ্যের তালিকা পাতা ধরে

অ্যাপের “রাজশাহীর পণ্য, ৭০০ টাকার নিচে, দাম অনুযায়ী” পাতা:

@Transactional(readOnly = true)
public Page<ProductCard> cheapFrom(String district, int page) {
    Pageable pageable = PageRequest.of(page, 20, Sort.by("price").ascending().and(Sort.by("id")));
    return products.findByDistrictAndPriceLessThan(district, new BigDecimal("700"), pageable)
                   .map(ProductCard::from);                // entity → record DTO
}

Hibernate: select p1_0.id,p1_0.district,p1_0.name,p1_0.price,... from product p1_0
           where p1_0.district=? and p1_0.price<? order by p1_0.price,p1_0.id
           offset ? rows fetch first ? rows only
Hibernate: select count(p1_0.id) from product p1_0 where p1_0.district=? and p1_0.price<?

দুটি query: এক পাতার সারি, আর মোট সংখ্যা (“২৩টি পণ্য, ২ পাতা”)। পাতা কাটার SQL ডেটাবেসভেদে আলাদা (LIMIT/OFFSET বা FETCH FIRST). লক্ষ করুন, sort-এ শেষে id যোগ করেছি — একই দামের অনেক পণ্য থাকলে ক্রম স্থির না হলে একই পণ্য দুই পাতায় আসতে পারে। মোট সংখ্যার দরকার না থাকলে (“আরও দেখুন” বোতাম) Page-এর বদলে Slice ফেরত দিন — count query বাঁচে। আর অনেক গভীর পাতায় (offset 100000) ডেটাবেসকে আগের সব সারি পেরোতে হয়; সেখানে “শেষ দেখা id-এর পর থেকে” ধরনের keyset pagination দ্রুত।

projection — জেলাভিত্তিক বিক্রির রিপোর্ট

পড়ার endpoint-এ পুরো entity আনার দরকার নেই। entity আনলে সব কলাম আসে, প্রতিটি খাতায় ওঠে, snapshot তৈরি হয় — অথচ আমরা কিছু বদলাব না। projection মানে query থেকে সরাসরি শুধু দরকারি কলাম একটি ছোট টাইপে আনা। মালিক জানতে চান গত মাসে কোন জেলায় কত বিক্রি:

public record DistrictSales(String district, long orders, BigDecimal revenue) {}   // record DTO

public interface OrderRepository extends JpaRepository<Order, Long> {
    @Query("""
        select new com.shop.report.DistrictSales(
                   o.deliveryAddress.district, count(distinct o.id), sum(i.unitPrice * i.quantity))
        from Order o join o.items i
        where o.placedAt >= :from and o.status <> com.shop.OrderStatus.CANCELLED
        group by o.deliveryAddress.district
        order by sum(i.unitPrice * i.quantity) desc
        """)
    List<DistrictSales> salesByDistrict(@Param("from") Instant from);
}

DistrictSales[district=Dhaka, orders=412, revenue=518300.00]
DistrictSales[district=Chattogram, orders=187, revenue=231950.00]
DistrictSales[district=Rajshahi, orders=96, revenue=104200.00]

select new … হলো JPQL-এর constructor expression: প্রতিটি ফল-সারি দিয়ে record-এর constructor ডাকা হয় (পুরো package-সহ নাম লাগে)। এটা managed নয়, খাতায় ওঠে না, snapshot নেই — সবচেয়ে হালকা। Spring Data-তে আরেকটি পথ interface projection: interface DistrictSales { String getDistrict(); Long getOrders(); BigDecimal getRevenue(); } আর JPQL-এ প্রতিটি কলামের as district-এর মতো নাম। দুটোই ভালো; record-এ টাইপ বেশি স্পষ্ট। নিয়ম মনে রাখুন: বদলানোর জন্য entity, দেখানোর জন্য projection.

৭ · transaction — @Transactional-এর সীমা, ফাঁদ আর optimistic locking

পর্ব ৪৯-এ হাতে setAutoCommit(false), commit(), rollback() লিখেছেন। Spring-এ সেটা একটি annotation: service method-এ @Transactional. অর্ডার নেওয়ার পুরো কাজ — স্টক কমানো, অর্ডার আর আইটেম লেখা — একটি transaction:

@Service
public class OrderService {
    private final ProductRepository products;
    private final CustomerRepository customers;
    private final OrderRepository orders;
    // constructor injection (পর্ব ৫০) …

    @Transactional
    public long placeOrder(long customerId, Address address, List<CartLine> lines) {
        Customer c = customers.findById(customerId).orElseThrow(() -> new NotFoundException("customer"));
        Order order = new Order(c, address);
        for (CartLine line : lines) {
            Product p = products.findById(line.productId()).orElseThrow(() -> new NotFoundException("product"));
            if (p.getStock() < line.qty()) throw new OutOfStockException(p.getId(), p.getStock());
            p.setStock(p.getStock() - line.qty());          // dirty checking → UPDATE (version-সহ)
            order.addItem(new OrderItem(p, line.qty(), p.getPrice()));
        }
        return orders.save(order).getId();                  // cascade → আইটেমগুলোর INSERT
    }
}

Spring অ্যাপ চালুর সময় OrderService-এর একটি proxy বানায় (পর্ব ৪৫-এর proxy আর AOP). controller আসলে proxy-র placeOrder ডাকে; proxy transaction শুরু করে, আসল method চালায়, তারপর ফল দেখে COMMIT বা ROLLBACK করে। এই একটি তথ্য থেকেই @Transactional-এর সব নিয়ম বোঝা যায়:

@Service
public class ReportService {
    public void nightly() {
        rebuild();                    // this.rebuild() — proxy-কে পাশ কাটায়
    }
    @Transactional
    public void rebuild() { ... }     // এখান থেকে ডাকলে transaction শুরুই হয় না!
}

optimistic locking — দুই কর্মী, একটি স্টক

ঈদের আগের রাত। রাজশাহীর ল্যাংড়া আমের স্টক ৫ বাক্স। একই মুহূর্তে দুজন গ্রাহক অর্ডার দিলেন — একজন ৩, আরেকজন ৪ বাক্স। দুটি request দুটি thread-এ, দুটি আলাদা transaction-এ। দুজনেই পড়ল স্টক ৫, দুজনেই দেখল “যথেষ্ট আছে”, দুজনেই লিখল। পর্ব ৪০-এর lost update — এবার টাকার হিসাবে: ৫ বাক্সে ৭ বাক্স বিক্রি। @Version ঠিক এটা ধরে ফেলে:

1@Version private long version;2Product p = products.findById(7L).orElseThrow();3p.setStock(p.getStock() - qty);4// commit-এর আগে flush:5update product set stock=?, version=?6       where id=7 and version=?7// ০টি সারি বদলালে → exception, ROLLBACK

একে বলে optimistic locking — আশাবাদী: ধরে নেওয়া হয় সংঘর্ষ কম হয়, তাই পড়ার সময় কিছু আটকানো হয় না, শুধু লেখার মুহূর্তে যাচাই। বিপরীত পথ pessimistic locking: @Lock(LockModeType.PESSIMISTIC_WRITE) দিয়ে পড়ার সময়েই select … for update, অন্যরা অপেক্ষা করে। খুব বেশি প্রতিযোগিতার একটি সারিতে (একটি ফ্ল্যাশ-সেলের একমাত্র পণ্য) pessimistic ভালো হতে পারে; সাধারণ দোকানে optimistic সহজ আর দ্রুত। আরেকটি সরল বিকল্প পর্ব ৪৯-এর মতো শর্তসহ একটি বাল্ক UPDATE: update product set stock = stock - :q where id = :id and stock >= :q, আর বদলানো সারির সংখ্যা দেখা। পর্ব ৫৫-এর ক্যাপস্টোনে দুজন গ্রাহক একসাথে শেষ পিসটি কেনার এই সমস্যাটিই আবার আসবে।

৮ · schema, টেস্ট আর পারফরম্যান্সের চেকলিস্ট

টেবিল কে বানাবে — ddl-auto বনাম migration

Hibernate entity দেখে টেবিল বানাতেও পারে। এটা নিয়ন্ত্রণ করে ddl-auto সেটিং:

Spring Boot নিজে থেকে মান ঠিক করে: H2-এর মতো embedded ডেটাবেসে আর কোনো migration টুল না থাকলে create-drop, অন্যথায় none. production-এ update কেন নয়? একটি field-এর নাম phone থেকে mobile করলে update নতুন খালি কলাম বানায় — পুরোনো কলামের লাখখানেক নম্বর আর পড়া হয় না। কোন বদল কখন হলো তার কোনো ইতিহাস নেই, পিছিয়ে যাওয়ার উপায় নেই, আর দুটি সার্ভার একসাথে চালু হলে দুজনেই টেবিল বদলাতে চায়। তাই পেশাদার প্রজেক্টে schema-র প্রতিটি বদল একটি ক্রমিক SQL ফাইলে লেখা হয় — database migration — Flyway (db/migration/V1__create_product.sql, V2__add_version.sql) বা Liquibase দিয়ে। ফাইলগুলো git-এ থাকে, code review হয়, প্রতিটি পরিবেশে একই ক্রমে চলে। Hibernate থাকে validate-এ, শুধু পাহারাদার হিসেবে।

টেস্ট — @DataJpaTest আর Testcontainers

@DataJpaTest
class ProductRepositoryTest {
    @Autowired ProductRepository repo;
    @Autowired TestEntityManager em;

    @Test
    void findsCheapProductsFromRajshahi() {
        em.persist(new Product("MANGO-1", "ল্যাংড়া আম ৫ কেজি", "Rajshahi", new BigDecimal("650"), 40));
        em.persist(new Product("MANGO-2", "হিমসাগর ১০ কেজি", "Rajshahi", new BigDecimal("1200"), 10));
        em.persist(new Product("DOI-1", "বগুড়ার দই", "Bogura", new BigDecimal("300"), 15));
        em.flush(); em.clear();                    // খাতা খালি — যাতে query সত্যিই ডেটাবেস থেকে পড়ে

        var page = repo.findByDistrictAndPriceLessThan("Rajshahi", new BigDecimal("700"), PageRequest.of(0, 10));
        assertEquals(List.of("MANGO-1"), page.map(Product::getSku).getContent());
    }
}

@DataJpaTest শুধু JPA অংশ চালু করে, আর প্রতিটি টেস্ট একটি transaction-এ চালিয়ে শেষে rollback করে — টেস্টগুলো একে অপরের ডেটা দেখে না। em.clear() না দিলে query-র ফল first-level cache থেকেও আসতে পারত, আর টেস্ট আসল SQL যাচাই না করেই পাস করত। ডিফল্টে এটা মেমরির ডেটাবেস ব্যবহার করে, কিন্তু H2 আর PostgreSQL-এর SQL পুরো এক নয় — native query, sequence বা JSON কলাম H2-তে পাস করে production-এ ভাঙতে পারে। তাই অনেক দল Testcontainers দিয়ে টেস্টের সময় Docker-এ আসল PostgreSQL চালায় (Spring Boot 3.1 থেকে @ServiceConnection এটা আরও সহজ করেছে)।

পারফরম্যান্সের চেকলিস্ট

logging.level.org.hibernate.SQL=debug                 # প্রতিটি SQL log-এ
logging.level.org.hibernate.orm.jdbc.bind=trace       # Hibernate 6: parameter-এর মান
spring.jpa.properties.hibernate.default_batch_fetch_size=16
spring.jpa.open-in-view=false
spring.jpa.hibernate.ddl-auto=validate

• SQL দেখুন। প্রতিটি নতুন endpoint একবার চালিয়ে log-এ গুনে দেখুন কয়টি SQL গেল। তালিকার আকার বাড়লে query-র সংখ্যা বাড়লে, সেটা N+1.
• সব সম্পর্ক LAZY; দরকারি জায়গায় join fetch, @EntityGraph, আর ডিফল্ট হিসেবে batch fetching.
• পড়ার endpoint-এ projection, আর service-এ @Transactional(readOnly = true).
• বড় batch-এ খাতা খালি রাখুন। লাখ সারি ঢোকাতে প্রতি কয়েকশো সারিতে flush() আর clear(), নয়তো খাতা ফুলে মেমরি শেষ। hibernate.jdbc.batch_size চালু করুন — আর মনে রাখুন, IDENTITY id-তে INSERT batch হয় না।
• open-in-view বন্ধ, আর কোনো entity কখনো সরাসরি JSON হয়ে বাইরে যাবে না (পর্ব ৫১)।
• index. যে কলামে খোঁজেন বা JOIN করেন (district, customer_id), তাতে index — migration ফাইলে (পর্ব ৪৯)।

৯ · AI-এর যুগে — AI-এর লেখা JPA কোড যাচাই

AI-কে “Order আর Customer entity বানাও” বললে চলার মতো কোড আসে, compile হয়, ছোট ডেটায় ঠিকঠাক চলে। JPA-র বিপদগুলো ঠিক সেখানেই, যেখানে ছোট ডেটায় কিছু টের পাওয়া যায় না। AI-এর লেখা JPA কোডে বারবার যা দেখা যায়:

AI-এর লেখা JPA কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি @ManyToOne আর @OneToOne-এ LAZY লেখা আছে
• প্রতিটি bidirectional সম্পর্কে এক দিকে mappedBy, আর দুই দিক মেলানোর helper method আছে
• cascade শুধু মালিক থেকে সন্তানের দিকে; স্বাধীন entity-তে কোনো REMOVE নেই
• SQL log চালু করে তালিকার endpoint চালিয়েছি; query-র সংখ্যা ডেটার আকারের সাথে বাড়ে না
• @Transactional শুধু service-এর public method-এ, আর কোথাও একই class থেকে ডাকা হয় না; checked exception-এ rollback দরকার হলে rollbackFor আছে
• কোনো controller entity ফেরত দেয় না; open-in-view=false
• স্টক বা ব্যালান্সের মতো একসাথে বদলানো ডেটায় @Version বা শর্তসহ UPDATE আছে
• production-এ ddl-auto validate বা none, schema Flyway/Liquibase-এ