Solved LeetCode 3761 with HashMap and Hibernate Entity Lifecycle

🚨 I almost overcomplicated this problem… but pattern recognition saved me. Day 25 of my Backend Developer Journey — and today was all about thinking in cycles 🔁 🧠 LeetCode Breakthrough Solved LeetCode 3488. Closest Equal Element Queries 💡 What clicked: → Group indices using HashMap → Treat indices as circular (important!) → Compare nearest left & right occurrences ⚡ The real trick: Not linear thinking… but circular distance calculation 🔍 Key Insight Instead of checking all elements: 👉 Preprocess positions 👉 Use modulo to simulate circular array 👉 Reduce time complexity significantly 🔗 My Submission: https://lnkd.in/gKBBY7ds ☕ Spring Boot Learning 🔄 Hibernate Entity Lifecycle Today I learned how Hibernate manages objects internally: 👉 Transient – Object created, not in DB 👉 Persistent – Connected to DB (tracked by Hibernate) 👉 Detached – Exists but not tracked 👉 Removed – Marked for deletion 💡 Why this matters: Understanding lifecycle = avoiding unexpected DB behavior 🧠 The Shift 👉 Problems are not always linear 👉 Sometimes the data structure defines the solution 👉 Backend isn’t just coding — it’s understanding system behavior 📘 Spring Boot Notes: https://lnkd.in/gRgxP7Th 📈 Day 25 Progress: ✅ Stronger problem-solving ✅ Better understanding of Hibernate internals ✅ Thinking beyond brute force 💬 Have you ever solved a problem only after changing the way you looked at it? #100DaysOfCode #BackendDevelopment #SpringBoot #Java #LeetCode #CodingJourney

Day 29. I enabled query logging for the first time. What I saw surprised me. I had this: List<User> users = userRepository.findAll(); Simple. Clean. One line. I assumed Hibernate was handling it efficiently. Then I added this: spring.jpa.show-sql=true And watched the logs. Not one query. Multiple hidden ones. → Fetch users → Then fetch relationships → Then more queries behind the scenes Hibernate wasn’t optimizing anything. It was executing exactly what I told it to — lazily, one relationship at a time. That’s when it clicked. ORM doesn’t optimize your queries. It executes what you tell it to. (see fix below 👇) Or better: 👉 Fetch only what you need (DTO projection) What I learned: → Hibernate is not magic → Default behavior is not always efficient → You are responsible for query performance The hard truth: → “It works” doesn’t mean “it’s optimized” → ORM hides complexity — it doesn’t remove it Writing code that runs is easy. Understanding what your database is actually doing is what makes you a backend developer. Have you ever checked your query logs and been surprised? 👇 Drop your experience #SpringBoot #Java #Hibernate #BackendDevelopment #Performance #JavaDeveloper

While debugging a Hibernate issue recently, I came across something interesting 👇 `org.hibernate.ObjectNotFoundException` — a small error with a big lesson. At first glance, it looked like a typical lazy loading problem. But the actual root cause was deeper. 🔍 What was happening? Hibernate created a proxy for a related entity, but when it tried to initialize it, the corresponding row didn’t exist in the database. 👉 In short: The application assumed data integrity, but the database told a different story. ⚠️ The tricky part? The exception wasn’t thrown during query execution. It appeared during debugging when `toString()` was triggered on a proxy object. 💡 Key learnings from this: 🔹 ORM frameworks don’t guarantee data consistency — your database does 🔹 Lazy loading can hide issues until runtime (or even debug time) 🔹 Using Lombok `@ToString` blindly on entities can backfire 🔹 Circular relationships (OneToMany ↔ ManyToOne) can lead to unexpected behavior 🛠 What helped fix it: ✔ Verifying referential integrity at the database level ✔ Avoiding unnecessary eager access during debugging ✔ Restricting `toString()` to only essential fields ✔ Using LEFT JOIN fetch where relationships may be optional 🚀 Takeaway: Most production issues are not about complex logic — they are about mismatches between your assumptions and actual data. Always trust your database more than your ORM. #Java #Hibernate #SpringBoot #BackendDevelopment #Debugging #SoftwareEngineering #Production #ProductionIssues #ErrorHandling

🚀 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗻 𝗢𝗿𝗱𝗲𝗿 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗦𝘆𝘀𝘁𝗲𝗺 𝗳𝗿𝗼𝗺 𝗦𝗰𝗿𝗮𝘁𝗰𝗵 — 𝗣𝗮𝗿𝘁 𝟭 Started working on a production-style Order Management System. Not a CRUD app — but a backend that handles concurrency, data consistency, and service decoupling the way real systems do. Core design choice: 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 Services don’t call each other directly. OrderService publishes an OrderCreatedEvent, and InventoryListener plus AuditListener react independently using Spring Application Events. This means no tight coupling. Adding a new listener requires zero changes to existing code. And if we switch to Kafka later, listeners remain completely untouched. 𝗪𝗵𝗮𝘁 𝗣𝗵𝗮𝘀𝗲 𝟭 𝗰𝗼𝘃𝗲𝗿𝘀 ✍️ 𝗣𝗲𝘀𝘀𝗶𝗺𝗶𝘀𝘁𝗶𝗰 𝗟𝗼𝗰𝗸𝗶𝗻𝗴 — Using @Lock(PESSIMISTIC_WRITE) on inventory queries. Two users, last item — one wins cleanly. No overselling. 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝗰𝘆 — Unique key per order ensures duplicate requests return the existing order, not a new one. 𝗜𝗺𝗺𝘂𝘁𝗮𝗯𝗹𝗲 𝗗𝗧𝗢𝘀 — Java Records with Bean Validation at the controller boundary. 𝗚𝗹𝗼𝗯𝗮𝗹 𝗘𝘅𝗰𝗲𝗽𝘁𝗶𝗼𝗻 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴 — Structured JSON errors, correct HTTP status codes, and no stack trace leaks. 𝗔𝘂𝗱𝗶𝘁 𝗧𝗿𝗮𝗶𝗹 — Every state transition is logged to order_events with timestamps. 𝗣𝗢𝗦𝗧 /𝗮𝗽𝗶/𝗼𝗿𝗱𝗲𝗿𝘀 → 𝗢𝗿𝗱𝗲𝗿𝗦𝗲𝗿𝘃𝗶𝗰𝗲 (𝘀𝘁𝗮𝘁𝘂𝘀: 𝗖𝗥𝗘𝗔𝗧𝗘𝗗) → 𝗽𝘂𝗯𝗹𝗶𝘀𝗵𝗲𝘀 𝗢𝗿𝗱𝗲𝗿𝗖𝗿𝗲𝗮𝘁𝗲𝗱𝗘𝘃𝗲𝗻𝘁 → 𝗜𝗻𝘃𝗲𝗻𝘁𝗼𝗿𝘆𝗟𝗶𝘀𝘁𝗲𝗻𝗲𝗿 (𝗿𝗲𝘀𝗲𝗿𝘃𝗲𝘀 𝘀𝘁𝗼𝗰𝗸 𝘄𝗶𝘁𝗵 𝗽𝗲𝘀𝘀𝗶𝗺𝗶𝘀𝘁𝗶𝗰 𝗹𝗼𝗰𝗸) → 𝗔𝘂𝗱𝗶𝘁𝗟𝗶𝘀𝘁𝗲𝗻𝗲𝗿 (𝗹𝗼𝗴𝘀 𝘁𝗼 𝗼𝗿𝗱𝗲𝗿_𝗲𝘃𝗲𝗻𝘁𝘀) 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸 Spring Boot 4 · Java 17 · Spring Data JPA · H2 · Hibernate 𝗡𝗲𝘅𝘁 Building a payment system using the Strategy Pattern with multiple methods and no if-else chains. But the real question is: what happens when payment fails after inventory is already deducted? Compensating transactions. Part 2 soon ✨ #Java #SpringBoot #SystemDesign #BackendEngineering #SoftwareArchitecture #BuildInPublic

🔥 𝗪𝗵𝗮𝘁 𝗮 𝗱𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 𝗷𝗼𝘂𝗿𝗻𝗲𝘆 𝘄𝗶𝘁𝗵 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 𝘁𝗼𝗱𝗮𝘆 — 𝗮𝗻𝗱 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝗺𝗼𝗿𝗲 𝗶𝗻 𝟮 𝗵𝗼𝘂𝗿𝘀 𝘁𝗵𝗮𝗻 𝗜 𝘄𝗼𝘂𝗹𝗱 𝗶𝗻 𝟮 𝘄𝗲𝗲𝗸𝘀 𝗼𝗳 𝗷𝘂𝘀𝘁 𝗿𝗲𝗮𝗱𝗶𝗻𝗴. Here's the full story: ❌ 𝗣𝗿𝗼𝗯𝗹𝗲𝗺: LazyInitializationException "Cannot lazily initialize collection of role Company.jobs — no session" My @OneToMany(fetch = LAZY) jobs list in Company was throwing this every time I hit the API. 🔁 𝗔𝘁𝘁𝗲𝗺𝗽𝘁 𝟭 — @𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻𝗮𝗹 Added it to the service method. Fixed the exception... but then I noticed something in the logs. Hibernate was firing N+1 queries: → 1 query for all companies → 1 query per company to fetch its jobs → 5 companies = 6 queries. Not good. 🔁 𝗔𝘁𝘁𝗲𝗺𝗽𝘁 𝟮 — 𝗙𝗲𝘁𝗰𝗵𝗧𝘆𝗽𝗲.𝗘𝗔𝗚𝗘𝗥 Worked, but it always loads jobs — even when I don't need them. A performance trap waiting to happen. ✅ 𝗙𝗶𝗻𝗮𝗹 𝗳𝗶𝘅 — 𝗝𝗢𝗜𝗡 𝗙𝗘𝗧𝗖𝗛 @Query("SELECT c FROM Company c LEFT JOIN FETCH c.jobs") → 1 single SQL query → No session dependency → No N+1 problem → Maximum performance 🚀 💡 𝗕𝗼𝗻𝘂𝘀 𝗹𝗲𝘀𝘀𝗼𝗻: Don't use @Lob on a String field in PostgreSQL with Hibernate 6. PostgreSQL LOBs use numeric OIDs internally — so Hibernate tries to read your text as a long and crashes with "bad value for type long". Removing @Lob fixed it instantly. 𝗧𝗵𝗲 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗷𝗼𝘂𝗿𝗻𝗲𝘆: LazyInitializationException → @Transactional (N+1 problem) → EAGER (always loads, bad practice) → JOIN FETCH ✅ (one query, perfect) Sometimes the best way to understand a tool deeply is to break it in every possible way first. 😄 #Java #SpringBoot #Hibernate #JPA #Backend #SpringAI #SpringUsers #JavaDevelopmentDesign

🚀 How Spring Data JPA Works Internally Today I took some time to deeply understand how Spring Data JPA actually works behind the scenes. Most of the time, we simply write: studentRepository.findAll(); But internally, a lot happens: We create a Repository Interface Spring creates a Proxy Object for it The proxy intercepts the method call Hibernate converts it into an SQL query The SQL runs on the database The result is returned as Java objects Simple flow: Your Code → Repository → Proxy Class → Hibernate → SQL Query → Database This is what makes Spring Data JPA so powerful and developer-friendly. ✔ Less boilerplate code ✔ Automatic CRUD operations ✔ Query generation from method names ✔ Seamless Hibernate integration ✔ Faster backend development Example: List<Student> students = studentRepository.findAll(); Behind the scenes, Spring and Hibernate handle everything automatically. It may look like magic when you start learning backend development, but once you understand the internal flow, it becomes much easier to work with. #Java #SpringBoot #SpringDataJPA #Hibernate #BackendDevelopment #Programming #SoftwareEngineering #JavaDeveloper #Coding #WebDevelopment

🚀 2 Weeks Learning Update – Hibernate & ORM Journey Over the past 2 weeks, I focused on strengthening my fundamentals of Hibernate and ORM concepts through practical learning 📚 What I Covered: 🔹 ORM (Object Relational Mapping) Learned how Hibernate maps Java objects to database tables, reducing the need for complex SQL. 🔹 Hibernate Architecture Understood key components like Session, SessionFactory, and how Hibernate manages data internally. 🔹 CRUD Operations Performed Create, Read, Update, and Delete operations using Hibernate. 🔹 Fetching Strategies ✔️ Lazy Loading vs Eager Loading Learned how data is fetched and its impact on performance. 🔹 Caching ✔️ Level 1 Cache (Session-level) ✔️ Level 2 Cache (SessionFactory-level) 🔹 Annotations ✔️ @GeneratedValue for automatic ID generation 🔹 Entity Relationships (Associations) ✔️ One-to-One ✔️ One-to-Many ✔️ Many-to-One ✔️ Many-to-Many 🔹 LOB Data Types ✔️ BLOB (Binary Large Object) ✔️ CLOB (Character Large Object) 🔹 HQL / JPQL Learned how to perform CRUD operations using object-oriented queries instead of SQL. 👉 These query languages are similar to SQL but work with objects instead of tables 💻 Project Link: 🔗 https://lnkd.in/gJGRzj7A 🎯 Key Takeaway: Hibernate simplifies database interaction by handling mapping, queries, and caching — making backend development more efficient and clean. 💭 My Thought: Understanding Hibernate deeply is helping me build a strong foundation for Spring Boot and real-world backend development 🚀 Consistency is everything — learning step by step 💪 #Hibernate #ORM #JavaDeveloper #BackendDevelopment #LearningJourney #SpringBoot #JPA #CodingLife #FutureEngineer

Today, I delved deeper into Spring Data JPA and its role in streamlining backend development for real-world applications. What I explored: - Mapping Java classes to database tables using @Entity and @Table - Handling primary keys with @Id and @GeneratedValue - Building the data access layer using JpaRepository - Writing custom queries with @Query (JPQL) - Understanding the differences between save(), findById(), findAll(), and delete() Advanced Insights: - How Spring Boot abstracts Hibernate complexity - The importance of proper entity relationships (OneToMany, ManyToOne) - Basic ideas of Lazy vs Eager fetching - Clean separation of layers: Controller → Service → Repository Hands-on Implementation: I built a Student Management REST API featuring: - Layered architecture - CRUD endpoints - Database integration using MySQL - API testing with Postman Learning Spring Boot extends beyond coding APIs; it's about designing scalable and maintainable backend systems. Next focus: Exception Handling & Validation in REST APIs.

🚀 Still writing complex JOIN queries to manage relationships? What if you could handle everything using simple Java objects… without worrying about SQL complexity? That’s exactly where Association Mapping in Spring Boot (JPA) becomes a game-changer 🔥 🔍 What this image explains Managing relationships between database tables is one of the most challenging parts of backend development. 👉 Association Mapping solves this by: ✔ Defining how entities are connected ✔ Mapping real-world relationships directly in your code ✔ Letting JPA handle the underlying SQL 📌 Types of Relationships 🔹 One-to-One → One entity is linked to exactly one other entity 🔹 One-to-Many → One parent can have multiple children 🔹 Many-to-One → Multiple entities can relate to one parent 🔹 Many-to-Many → Complex relationships using a join/lookup table 💡 Why It Matters ✔ Cleaner & more readable code ✔ Maintains strong data integrity ✔ Reduces the need for complex SQL queries ✔ Improves scalability and maintainability 🔥 Core Insight: Stop thinking in tables… Start thinking in objects and relationships — JPA will handle the rest. 💬 Quick Question: Which mapping do you use most in real projects — One-to-Many or Many-to-One? #SpringBoot #Java #JPA #Hibernate #BackendDevelopment #SoftwareEngineering #DatabaseDesign #LearningInPublic #Developers #TechContent

🚀 Day21 – Hibernate One-to-One Mapping Today I explored One-to-One relationship in Hibernate, a fundamental concept for linking two entities directly. 🔹 What I Worked On: ✔️ Implemented One-to-One mapping using annotations ✔️ Used @OneToOne and @JoinColumn 🔗 ✔️ Connected two entities with a single relationship ✔️ Stored linked data across tables 🔹 Concept Understanding: 👉 One record in a table is linked to exactly one record in another 👉 Example: One Student → One ID Card 🔹 Workflow: ➡️ Created two entity classes ➡️ Applied @OneToOne mapping ➡️ Configured Hibernate ➡️ Saved linked objects ➡️ Verified relationship in database ✅ 🔹 Key Learnings: ✨ Clear understanding of One-to-One relationships ✨ Learned how foreign keys work in mapping ✨ Understood uni-directional vs bi-directional mapping ✨ Improved ORM design concepts 🔹 Challenges Faced: ⚡ Deciding owning side of relationship ⚡ Correct usage of @JoinColumn ⚡ Handling cascading operations 🔹 What’s Next: 🚀 Explore One-to-Many mapping 🚀 Perform CRUD with relationships 🚀 Dive deeper into fetch types #Java #Hibernate #ORM #BackendDevelopment #LearningJourney Guided by, Anand Kumar Buddarapu sir, Saketh Kallepu sir, Uppugundla Sairam sir.