Introduction: এই কনটেন্টটি মূলত একটি টেকনিক্যাল প্রেজেন্টেশনের সারসংক্ষেপ, যেখানে Jens Schauder আলোচনা করেছেন কীভাবে একটি প্রোজেক্টকে Spring Data JPA থেকে সরিয়ে Spring Data JDBC-তে নিয়ে আসা যায়। অনেকে মনে করেন এটা খুব কঠিন, কিন্তু সঠিক পরিকল্পনা থাকলে ধাপে ধাপে (Baby steps) এটি করা সম্ভব। মূলত কোডের জটিলতা কমানো এবং ডাটাবেসের ওপর আরও বেশি নিয়ন্ত্রণ পাওয়ার জন্যই এই মাইগ্রেশন করা হয়।
১. এগ্রিগেট (Aggregates) চেনা এবং অপ্রয়োজনীয় রিপোজিটরি সরানো
ভিডিও রেফারেন্স: [14:22] থেকে [21:18] পর্যন্ত।
মাইগ্রেশনের প্রথম এবং প্রধান ধাপ হলো আপনার ডোমেইন মডেলের Aggregates গুলোকে চেনা।
বিস্তারিত ব্যাখ্যা: JPA-তে আমরা সাধারণত প্রতিটি টেবিলের জন্য আলাদা আলাদা Repository তৈরি করি। কিন্তু Spring Data JDBC কাজ করে 'Aggregate' বা গুচ্ছ আকারে। একটি এগ্রিগেট হলো কতগুলো ক্লাসের সমষ্টি যেখানে একটি প্রধান ক্লাস (Aggregate Root) থাকে এবং বাকিগুলো তার অধীনে থাকে।
-
যেমন: একটি 'Shipment' (চালান) এবং তার ভেতরে থাকা 'Items' (পণ্য)। এখানে Shipment হলো মেইন রুট।
-
আপনার কাজ হবে সেই সব বাড়তি Repository ডিলিট করে দেওয়া যা সরাসরি এগ্রিগেটের ভেতরের ছোট ছোট এনটিটি (যেমন Item) হ্যান্ডেল করে। এখন থেকে সব কাজ হবে মেইন রুটের (Shipment) মাধ্যমে।
সহজ ভাষায় কঠিন শব্দ:
-
Aggregate (এগ্রিগেট): অনেকগুলো সম্পর্কিত জিনিসের একটি দল বা গ্রুপ।
-
Repository (রিপোজিটরি): ডাটাবেসের সাথে তথ্য আদান-প্রদান করার একটি মাধ্যম বা গেটওয়ে।
২. মিকাডো মেথড (Mikado Method) ব্যবহার করা
রেফারেন্স: এই বিষয়টি পুরো আলোচনার মূল ভিত্তি হিসেবে কাজ করে।
মাইগ্রেশন করার সময় অনেক সময় একটি কোড পরিবর্তন করলে দেখা যায় অন্য ১০টি জায়গায় ইরর (Error) দিচ্ছে। এটি এড়াতে Mikado Method জাদুর মতো কাজ করে।
বিস্তারিত ব্যাখ্যা: এটি একটি রিফ্যাক্টরিং টেকনিক। ১. প্রথমে একটি বড় লক্ষ্য কাগজে লিখুন। ২. সেটি করতে গিয়ে যদি দেখেন অন্য কিছু বাধা দিচ্ছে, তবে আগের কাজ 'Undo' বা বাতিল করে সেই ছোট সমস্যাটি আগে সমাধান করুন। ৩. এভাবে ছোট ছোট সফল পরিবর্তনের মাধ্যমে বড় লক্ষ্যে পৌঁছান। একে 'Baby Steps' বলা হয়। এতে আপনার কোডবেস সবসময় সচল থাকে এবং মাঝপথে প্রোজেক্ট আটকে যাওয়ার ভয় থাকে না।
৩. সেভ স্টেটমেন্ট (Save Statements) সরাসরি ব্যবহার করা
ভিডিও রেফারেন্স: [21:18] এর পর থেকে।
JPA-তে একটি সুবিধা (বা অসুবিধা) আছে যাকে বলা হয় 'Dirty Checking'। আপনি যদি ট্রানজ্যাকশনের ভেতর কোনো ডাটা পরিবর্তন করেন, তবে আলাদা করে .save() কল না করলেও তা ডাটাবেসে সেভ হয়ে যায়। কিন্তু JDBC-তে এটি হয় না।
বিস্তারিত ব্যাখ্যা: Spring Data JDBC-তে কোনো ডাটা পরিবর্তন করলে আপনাকে অবশ্যই স্পষ্টভাবে repository.save(entity) মেথডটি কল করতে হবে। কারণ JDBC-র এনটিটিগুলো সাধারণ জাভা ক্লাসের মতো কাজ করে, এর পেছনে কোনো ম্যাজিক প্রক্সি থাকে না।
সহজ ভাষায় কঠিন শব্দ:
- Explicit (এক্সপ্লিসিট): কোনো কিছু সরাসরি বা স্পষ্টভাবে বলে দেওয়া।
৪. রিলেশন বা সম্পর্ক সহজ করা (Bidirectional to Unidirectional)
JPA-তে আমরা অনেক সময় দ্বিমুখী সম্পর্ক (Bidirectional reference) রাখি (যেমন: A চেনে B-কে, আবার B-ও চেনে A-কে)। Spring Data JDBC এটি সাপোর্ট করে না এবং এর প্রয়োজনও নেই।
বিস্তারিত ব্যাখ্যা: আপনাকে সিদ্ধান্ত নিতে হবে কোন দিক থেকে সম্পর্কটি থাকবে। সাধারণত মেইন অবজেক্ট থেকে সাব-অবজেক্টের দিকে রেফারেন্স রাখা হয়। যেমন: Shipment থেকে Customer-এর দিকে। এতে কোড অনেক পরিষ্কার হয় এবং গোলকধাঁধা তৈরি হয় না।
কোডিং উদাহরণ (ID Generator)
যখন আপনি JPA থেকে JDBC-তে আসবেন, তখন আইডি জেনারেশন নিয়ে কাজ করতে হতে পারে। নিচে একটি কোড স্নিপেট দেওয়া হলো যা ডাটা সেভ করার আগে আইডি তৈরি করে নেয়:
Java
public class BeforeConvertCallback implements BeforeConvertCallback<Object> {
private final JdbcTemplate jdbcTemplate;
public BeforeConvertCallback(JdbcTemplate jdbcTemplate) {
this.jdbcTemplate = jdbcTemplate;
}
@Override
public Object onBeforeConvert(Object entity) {
// যদি আইডির মান খালি থাকে, তবে ডাটাবেস সিকোয়েন্স থেকে নতুন আইডি এনে বসিয়ে দাও
if (entity instanceof MyEntity && ((MyEntity) entity).getId() == null) {
Long id = jdbcTemplate.queryForObject("SELECT nextval('my_sequence')", Long.class);
((MyEntity) entity).setId(id);
}
return entity;
}
}
ব্যাখ্যা: এই কোডটি মূলত ডাটাবেসে তথ্য পাঠানোর ঠিক আগে চেক করে যে তার কোনো আইডি আছে কি না। না থাকলে সে একটি নতুন নম্বর (ID) সংগ্রহ করে বসিয়ে দেয়, যাতে ডাটাবেস বুঝতে পারে এটি একটি নতুন এন্ট্রি।
বিশ্লেষণ ও আমার ভাবনা (Analysis & Perception)
সারাংশ ও উদ্দেশ্য: কন্টেন্ট ক্রিয়েটর Jens Schauder বোঝাতে চেয়েছেন যে, Spring Data JDBC ব্যবহার করলে আপনার অ্যাপ্লিকেশন অনেক বেশি "Predictable" বা অনুমানযোগ্য হয়। JPA অনেক সময় আড়ালে অনেক কিছু করে যা বড় প্রোজেক্টে পারফরম্যান্সের সমস্যা তৈরি করে। মাইগ্রেশন মানে শুধু কোড পাল্টানো নয়, বরং আপনার অ্যাপ্লিকেশনের আর্কিটেকচার বা গঠনকে আরও মজবুত করা।
বাস্তবতা ও সম্ভাবনা: ১০০টি এনটিটি আছে এমন বড় প্রোজেক্টে একবারে মাইগ্রেশন করা প্রায় অসম্ভব এবং ঝুঁকিপূর্ণ। তাই বক্তার পরামর্শ হলো—নতুন ফিচারের জন্য JDBC ব্যবহার শুরু করুন এবং পুরাতনগুলো ধীরে ধীরে পরিবর্তন করুন (Mixed approach)।
বিকল্প ও পরামর্শ:
-
যদি আপনার প্রোজেক্ট খুব ছোট হয় এবং JPA-তে কোনো সমস্যা না হয়, তবে মাইগ্রেশনের প্রয়োজন নেই।
-
পারফরম্যান্স ক্রিটিক্যাল অ্যাপ্লিকেশন হলে অবশ্যই JDBC ভালো বিকল্প।
-
মাইগ্রেশনের আগে পর্যাপ্ত 'Unit Test' লিখে রাখা বাধ্যতামূলক, যাতে কোড পরিবর্তনের পর কোনো ফিচার ভেঙে না যায়।
সহজ সাজেশন: "Baby steps" বা ছোট ছোট পদক্ষেপে এগোলে যেকোনো বড় মাইগ্রেশন সফল করা সম্ভব। তাড়াহুড়ো না করে আগে ডোমেইন মডেল ঠিক করাই হবে বুদ্ধিমানের কাজ।
[
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)
মন্তব্যসমূহ
একটি মন্তব্য পোস্ট করুন
আপনার সমস্যাটি কমেন্ট করে আমাদের জানান :-d