Spring Data JPA থেকে Spring Data JDBC-তে মাইগ্রেশনের সহজ নির্দেশিকা

Introduction এই ভিডিওতে জেন্স শাউডার (Jens Schauder) আলোচনা করেছেন কীভাবে একটি প্রজেক্টকে Spring Data JPA থেকে Spring Data JDBC-তে মাইগ্রেট বা পরিবর্তন করা যায়। JPA অনেক সময় জটিল হয়ে পড়ে, তাই অনেকে সহজ এবং নিয়ন্ত্রিত পদ্ধতির জন্য JDBC-তে ফিরে আসতে চান। ভিডিওটিতে কোনো তাড়াহুড়ো না করে ধাপে ধাপে, ছোট ছোট পরিবর্তনের মাধ্যমে কীভাবে এই বড় কাজটি সম্পন্ন করা যায়, তার একটি পরিষ্কার রোডম্যাপ দেওয়া হয়েছে।

টপিক ১: মাইগ্রেশনের মূল ভিত্তি (The Foundations) মাইগ্রেশন শুরু করার আগে কিছু প্রস্তুতি নেওয়া খুব জরুরি।

• ভিডিও রেফারেন্স: [04:45]

• বিস্তারিত: মাইগ্রেশন শুরু করার আগে আপনার কোডবেসে অবশ্যই শক্তিশালী 'Tests' থাকতে হবে। যদি কোনো বড় পরিবর্তন করার পর কিছু ভেঙে যায়, তবে আপনার টেস্ট যেন সেটা সাথে সাথে ধরতে পারে। জেন্স এখানে 'Baby Steps' বা একদম ছোট ছোট ধাপে কাজ করার পরামর্শ দিয়েছেন।

• Mikado Method: এটি একটি বিশেষ রিফ্যাক্টরিং পদ্ধতি [07:14]। এর মূল কথা হলো—একটি বড় লক্ষ্য ঠিক করা, তারপর সেটি অর্জনে কী কী ছোট বাধা আছে তা খুঁজে বের করা। যদি কোনো পরিবর্তন করতে গিয়ে কোড 'Red' হয়ে যায় (এরর দেয়), তবে সাথে সাথে পরিবর্তনটি 'Undo' করে আগে গোড়ার সমস্যা সমাধান করতে হবে।

• সহজ ব্যাখ্যা: Refactoring মানে হলো কোডের বাইরের আউটপুট ঠিক রেখে ভেতরের গঠন সুন্দর করা। Undo মানে আগের অবস্থায় ফিরে যাওয়া।

টপিক ২: অ্যাগ্রিগেট (Aggregates) চেনা ও রিপোজিটরি কমানো JPA-তে আমরা সবকিছুর জন্য আলাদা আলাদা রিপোজিটরি বানাই, কিন্তু JDBC-তে আমাদের 'Aggregate' কনসেপ্ট বুঝতে হবে।

• ভিডিও রেফারেন্স: [15:20]

• বিস্তারিত: একটি 'Aggregate' হলো কতগুলো ক্লাসের গুচ্ছ যা একসাথে কাজ করে। যেমন—একটি 'Shipment' (চালান) এবং তার ভেতরের 'Items' (পণ্য)। আইটেমগুলো শিপমেন্ট ছাড়া একা চলতে পারে না। তাই 'Item' এর জন্য আলাদা কোনো রিপোজিটরি রাখা যাবে না [16:51]। সব কাজ হবে মূল 'Shipment' ক্লাসের মাধ্যমে।

• সহজ ব্যাখ্যা: Aggregate Route হলো একটি বড় দলের নেতার মতো। আপনি যদি দলের ভেতরের কাউকে কিছু বলতে চান, তবে নেতার মাধ্যমেই বলতে হবে।

টপিক ৩: সেভ স্টেটমেন্ট স্পষ্ট করা (Explicit Save Statements) JPA নিজে থেকেই অনেক কিছু সেভ করে দেয়, যা JDBC-তে হয় না।

• ভিডিও রেফারেন্স: [21:18]

• বিস্তারিত: JPA-তে কোনো অবজেক্ট পরিবর্তন করলে ট্রানজ্যাকশন শেষে তা অটোমেটিক সেভ হয়ে যায়। কিন্তু JDBC-তে আপনাকে স্পষ্টভাবে .save() মেথড কল করতে হবে। মাইগ্রেশনের আগে আপনার JPA কোডেই সব জায়গায় ম্যানুয়ালি সেভ মেথড লিখে প্র্যাকটিস শুরু করা উচিত [22:32]।

• সহজ ব্যাখ্যা: Explicit মানে হলো কোনো কাজ পরিষ্কারভাবে নিজে হাতে করা, অটোমেটিক কিছুর ওপর ভরসা না করা।

টপিক ৪: রিলেশনশিপ বা সম্পর্ক সহজ করা JPA-তে দুইমুখী (Bidirectional) সম্পর্ক রাখা সহজ, কিন্তু JDBC-তে এটি করা যায় না।

• ভিডিও রেফারেন্স: [24:41]

• বিস্তারিত: যদি 'Customer' এবং 'Shipment' একে অপরকে চেনে, তবে আপনাকে যেকোনো একদিক বেছে নিতে হবে। সাধারণত 'Shipment' এর ভেতর 'Customer ID' রাখাই ভালো। এছাড়া Many-to-Many সম্পর্কের ক্ষেত্রে JDBC-তে একটি আলাদা ক্লাস (Join Table Entity) তৈরি করতে হয় [27:50]।

• সহজ ব্যাখ্যা: Bidirectional মানে হলো 'A' চেনে 'B' কে, আবার 'B' চেনে 'A' কে। JDBC বলে শুধু একজন একজনকে চিনলেই কাজ চলে যাবে।

টপিক ৫: কোড পরিবর্তন এবং আইডি জেনারেশন সবশেষে আমাদের প্রোজেক্টে JDBC ডিপেন্ডেন্সি যোগ করতে হবে।

• ভিডিও রেফারেন্স: [32:07]

• বিস্তারিত: Spring Boot ব্যবহার করলে spring-boot-starter-data-jdbc যোগ করতে হবে। যেহেতু JPA এবং JDBC-এর আইডি তৈরির পদ্ধতি ভিন্ন হতে পারে, তাই অনেক সময় একটি 'BeforeConvertCallback' ব্যবহার করে ম্যানুয়ালি আইডি জেনারেট করতে হয় [33:39]।

কোডিং উদাহরণ ও ব্যাখ্যা: নিচে একটি আইডি জেনারেটরের উদাহরণ দেওয়া হলো:

Java

public class MyIdGenerator implements BeforeConvertCallback<Object> {
    private final JdbcTemplate jdbcTemplate;

    public MyIdGenerator(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    @Override
    public Object onBeforeConvert(Object entity) {
        // যদি আইডির মান খালি (null) থাকে, তবে ডাটাবেস সিকুয়েন্স থেকে নতুন আইডি আনো
        if (getId(entity) == null) {
            Long id = jdbcTemplate.queryForObject("SELECT nextval('my_sequence')", Long.class);
            setId(entity, id);
        }
        return entity;
    }
} 

ব্যাখ্যা: এই কোডটি ডাটাবেসে তথ্য সেভ করার ঠিক আগে চেক করে যে আইডির মান আছে কি না। না থাকলে এটি সিকুয়েন্স থেকে একটি নতুন নাম্বার নিয়ে এসে বসিয়ে দেয়। এর ফলে ডাটাবেসে ডুপ্লিকেট আইডি হওয়ার ভয় থাকে না।

Analysis & Thinking কন্টেন্ট ক্রিয়েটর এখানে বোঝাতে চেয়েছেন যে, টেকনোলজি পরিবর্তন করা মানে শুধু লাইব্রেরি বদলে ফেলা নয়, বরং চিন্তাধারায় পরিবর্তন আনা। JPA আমাদের অনেক আলস্য দেয় (যেমন—অটো সেভ, লেজি লোডিং), যা বড় প্রজেক্টে পারফরম্যান্সের সমস্যা তৈরি করতে পারে।

আমার মতামত ও বিকল্প: ১. বাস্তবতা: সম্পূর্ণ মাইগ্রেশন অনেক ব্যয়বহুল এবং সময়সাপেক্ষ। ২. বিকল্প: আপনি চাইলে পুরো প্রজেক্ট মাইগ্রেট না করে শুধু নতুন মডিউলগুলো Spring Data JDBC-তে লিখতে পারেন। দুটি ফ্রেমওয়ার্ক একই প্রজেক্টে পাশাপাশি চলতে পারে [39:46]। ৩. পরামর্শ: যদি আপনার প্রজেক্টের ডাটাবেস ডিজাইন খুব জটিল হয় এবং আপনি ডাটাবেসের ওপর পূর্ণ নিয়ন্ত্রণ চান, তবেই JDBC-তে যান। নতুবা JPA-এর ভেতরেই 'Aggregate' এর নিয়মগুলো মেনে চললে কোড অনেক বেশি পরিষ্কার হবে।

সহজ ভাষায় কঠিন শব্দের ব্যাখ্যা:

• Persistence Context: এটি JPA-এর একটি ড্রয়ারের মতো যেখানে সে সব ডেটা সাময়িকভাবে জমা রাখে।

• Cascade: মানে হলো বাবা অবজেক্টকে সেভ করলে সন্তান অবজেক্টও যেন নিজে নিজে সেভ হয়ে যায়।

• Modulith: এটি 'Monolith' (একই সাথে সব কোড) এবং 'Modules' (আলাদা আলাদা ভাগ) এর সংমিশ্রণ।

[

Migrating from (Spring Data) JPA to Spring Data JDBC by Jens Schauder @ Spring I/O 2024

Spring I/O · 27K views

](http://www.youtube.com/watch?v=WYa9n0F4CRM)