Sumit Jindal’s Post

How to Create a Composite Primary Key in JPA Sometimes a single column isn’t enough to uniquely identify a record - that’s when we use a composite primary key. JPA gives two clean ways to implement it: @IdClass and @EmbeddedId. > The @Embeddable class holds the combined key fields. > The entity uses @EmbeddedId to mark the composite key. When to use: When two or more fields together uniquely identify a row When modeling many-to-many join tables When avoiding auto-generated IDs Composite keys keep your data consistent and enforce real-world uniqueness directly in the database. #SpringBoot #JPA #Hibernate #Java

𝗝𝗮𝘃𝗮 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗮𝗻𝗱 𝗝𝗗𝗕𝗖 – 𝗦𝗼𝗺𝗲 𝗥𝗲𝗮𝗹 𝗟𝗲𝘀𝘀𝗼𝗻𝘀 I 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 While building real Java backend projects, I thought I knew JDBC… but I actually learned a lot once I started digging deeper. Here are a few insights that changed how I work with databases: 💡 1. SQL isn’t magic, it’s logic: Understanding how JDBC talks to the database makes you write queries that are faster and cleaner. 💡 2. PreparedStatement > Statement: It’s not just about security (bye-bye SQL injection), but also about performance and maintainability. 💡 3. Closing connections is not optional: Resource leaks = headaches. Using try-with-resources is a small step but saves huge debugging time. 💡 4. Debugging becomes easier: Slow queries, missing commits, or connection leaks? JDBC gives you the tools to spot them before they hit production. 💡 5. Foundation for bigger frameworks: Once JDBC clicks, Spring Boot and Hibernate feel much easier to work with. 📌 Key takeaway: Understanding the basics deeply makes everything else smoother. JDBC taught me to respect SQL, manage data properly, and write backend code that lasts. #Java #JDBC #BackendDevelopment #MySQL #SpringBoot #Programming #Developers #LearningJourney

🔥 Ever faced “schema validation failed” in Spring Boot? Then you must understand what ddl-auto=validate really does! 🧠💡 I’ve just dropped a new YouTube video explaining how Hibernate’s ddl-auto=validate checks if your entity classes and database schema are in sync — before your app even starts. 🎯 In this short, practical demo, you’ll learn: ✅ How ddl-auto=validate works behind the scenes ✅ What happens when things don’t match ✅ When it’s safe (and not so safe) to use it in real projects ✅ Live example with MySQL 🧩 👉 Check it out now and level up your JPA + Hibernate understanding! 🎥 Watch here: https://lnkd.in/dPYQjxJB #SpringBoot #Hibernate #JPA #JavaDeveloper #BackendDevelopment #Java #Microservices #SpringFramework #CodingCommunity #LearnJava

Java Performance Tip 🚀 Dealing with large datasets in Spring Data JPA? Stop loading everything into memory! Use Stream-based queries with proper fetch size configuration for better memory management and performance. ✅ Old way: Loads entire result set into memory - potential OutOfMemoryError ✅ New way: Streams data in batches - efficient memory usage and better performance Key Benefits: 🎯 Prevents OutOfMemoryError with large datasets ⚡ Processes data in chunks (batch of 1000 records) 💾 Lower memory footprint 🔄 Works seamlessly with Java Streams API 📊 Perfect for data processing and reporting Pro Tips: Always close streams properly (use try-with-resources) Use @Transactional(readOnly = true) on service methods #Java #SpringBoot #SpringData #JPA #Hibernate #Performance #BestPractices #CleanCode #SoftwareDevelopment #BackendDevelopment #TechTips

💡 Day 3 of my 𝗝𝗮𝘃𝗮 𝗕𝗮𝗰𝗸𝗲𝗻𝗱 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗼𝗳 𝘁𝗵𝗲 𝗗𝗮𝘆 𝘀𝗲𝗿𝗶𝗲𝘀: 🧠 Question: You’re working on a Spring Boot application that interacts with a relational database. You notice that for every request, multiple queries are executed for fetching related entities - causing performance issues. 👉 What is the N+1 query problem in JPA/Hibernate, and how can you avoid it? ✅ Answer: The N+1 query problem happens when Hibernate fires: 1 query to fetch parent records N queries to fetch child records for each parent This results in N+1 queries, hurting performance. To avoid it: > Use fetch join 𝘚𝘌𝘓𝘌𝘊𝘛 𝘶 𝘍𝘙𝘖𝘔 𝘜𝘴𝘦𝘳 𝘶 𝘑𝘖𝘐𝘕 𝘍𝘌𝘛𝘊𝘏 𝘶.𝘰𝘳𝘥𝘦𝘳𝘴 > Use @EntityGraph to pre-fetch relationships > Enable batch fetching 𝘩𝘪𝘣𝘦𝘳𝘯𝘢𝘵𝘦.𝘥𝘦𝘧𝘢𝘶𝘭𝘵_𝘣𝘢𝘵𝘤𝘩_𝘧𝘦𝘵𝘤𝘩_𝘴𝘪𝘻𝘦=20 > Always monitor SQL logs to detect hidden N+1 issues. ✅ Fetch joins, entity graphs, and batch fetching = faster DB access & fewer queries ⚡ See you tomorrow for Day 4 👋 #Java #SpringBoot #Hibernate #JPA #Performance #BackendDeveloper #ContinuousLearning #QuestionOfTheDay

🐛 Bugs & Beyond #5 — The Legacy Method from Hell 😈 ⚠️ The Problem: While modernizing our old Java project, I stumbled upon this beauty: findAllByStatusAndCreationTimestampLessThanEqualAndMerchantBuyerPlatformsIdOrderByCreationTimestampAscIdAsc Yes. That’s one single method name. Symptoms: 🧩 Developers too scared to touch it 📉 Zero readability 💥 Any new filter meant adding another 10 words 🧠 Nobody remembered what it actually did Root Cause: Legacy Spring Data JPA derived query hell — logic jammed into the method name itself. Every extra condition = one more And/Or/By… until your IDE scrolls horizontally like a train. 🚂 The Fix: Go Modern. Go Readable. Use the @Query annotation or Specification API to express logic clearly. Before: findAllByStatusAndCreationTimestampLessThanEqualAndMerchantBuyerPlatformsIdOrderByCreationTimestampAscIdAsc After: @Query(""" SELECT o FROM Order o WHERE o.status = :status AND o.creationTimestamp <= :timestamp AND https://lnkd.in/g5esQGeE = :platformId ORDER BY o.creationTimestamp, o.id """) List<Order> findEligibleOrders(...); Results: ✅ Readable, maintainable queries ✅ Easier to debug & extend ✅ New devs no longer crying in the stand-up Key Takeaways: 😵 Avoid ultra-long derived query names — they’re not badges of honor. 🧠 Prefer @Query or Specification for complex conditions. 🧹 Refactoring legacy JPA methods is spring cleaning for your sanity. #Java #SpringBoot #JPA #Hibernate #CodeSmell #LegacyCode #Refactoring #CleanCode #BackendDevelopment #SystemDesign #ORM #ReadableCode #SoftwareEngineering #BugsAndBeyond #DevLife #JavaTips #Programming #CodeQuality #SpringDataJPA

When (and Why) to Use JPA Criteria API The Criteria API in JPA lets you build queries dynamically using Java code instead of plain strings. It’s especially useful when query conditions depend on user input or runtime parameters. When to Use It: 1. Dynamic Queries - When you don’t know all filter conditions beforehand. 2. Type Safety – Queries are checked at compile time (unlike JPQL strings). 3. Complex Queries - Easier to combine multiple predicates, joins, and sorting dynamically. 4. When building APIs with flexible filters or search features. For simple static queries, stick to JPQL or repository methods. Use Criteria API when flexibility and dynamic conditions matter. #JPA #Hibernate #Java

Hibernate’s N+1 Problem — The Silent Performance Killer 😱 If your app feels slow even with small data — you might be a victim of the N+1 SELECT Problem in Hibernate 🐢 --- 🧩 What is the N+1 Problem? Imagine this 👇 You fetch all Departments (1 query), and for each department, Hibernate fires another query to get its Employees (N queries). ➡️ Total = N + 1 queries! 😬 List<Department> departments = session.createQuery("from Department", Department.class).list(); for (Department dept : departments) { System.out.println(dept.getEmployees().size()); } 💥 Result: 1 query for Departments + N queries for Employees = Performance Disaster! --- ⚡ The Fix — Use JOIN FETCH Tell Hibernate to fetch related data in a single query 🧠 List<Department> departments = session .createQuery("SELECT d FROM Department d JOIN FETCH d.employees", Department.class) .list(); ✅ Result: Only 1 query to fetch everything 🚀 --- 🧠 Pro Tips to Avoid N+1 Traps: 💡 Use @EntityGraph for flexible fetch strategies 💡 Avoid global EAGER fetching — it often backfires 💡 Enable show_sql or use p6spy to monitor queries --- 🔥 Remember: Small query issues today become big performance nightmares tomorrow. 💬 Have you ever battled the N+1 monster in production? How did you fix it? #Hibernate #SpringBoot #Java #JPA #BackendDevelopment #Performance #CodeOptimization #Microservices #Developers