Yogesh Gurav’s Post

𝗔 𝗹𝗼𝘁 𝗼𝗳 𝗦𝗽𝗿𝗶𝗻𝗴 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝘀𝘁𝗶𝗹𝗹 𝘁𝗵𝗶𝗻𝗸 𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 𝗺𝗲𝗮𝗻𝘀 𝗼𝗻𝗹𝘆:  • JPA method names  • @Query But if your queries are getting more complex, 𝗷𝗢𝗢𝗤 𝗶𝘀 𝗮𝗹𝘀𝗼 𝗮𝗻 𝗼𝗽𝘁𝗶𝗼𝗻 — and honestly, more developers should know about it. In Spring, you can implement database queries in multiple ways: 𝗷𝗢𝗢𝗤 Great when your application is 𝗦𝗤𝗟-𝗵𝗲𝗮𝘃𝘆. 𝙒𝙝𝙮 𝙥𝙚𝙤𝙥𝙡𝙚 𝙡𝙞𝙠𝙚 𝙞𝙩:  • type-safe SQL  • better for complex joins  • cleaner for reporting / analytics queries  • stays close to real SQL 𝘽𝙚𝙨𝙩 𝙛𝙤𝙧:  • advanced filtering  • multi-table joins  • database-driven applications 𝗝𝗗𝗕𝗖 The most direct way to talk to the database. 𝙒𝙝𝙮 𝙥𝙚𝙤𝙥𝙡𝙚 𝙪𝙨𝙚 𝙞𝙩:  • full control  • lightweight  • no ORM magic 𝙏𝙧𝙖𝙙𝙚𝙤𝙛𝙛:  • more boilerplate  • manual mapping  • less convenient as the project grows @𝗤𝘂𝗲𝗿𝘆 A very common middle ground in Spring. 𝙂𝙤𝙤𝙙 𝙛𝙤𝙧:  • custom repository queries  • when derived methods are not enough  • medium-complexity use cases 𝙏𝙧𝙖𝙙𝙚𝙤𝙛𝙛:  • query strings can get harder to maintain  • not ideal when SQL becomes a big part of the app 𝗝𝗣𝗔 𝗱𝗲𝗿𝗶𝘃𝗲𝗱 𝗺𝗲𝘁𝗵𝗼𝗱𝘀 The fastest option for simple queries. 𝙂𝙤𝙤𝙙 𝙛𝙤𝙧:  • CRUD  • small filters  • rapid development 𝙏𝙧𝙖𝙙𝙚𝙤𝙛𝙛:  • method names can become ugly very fast  • not made for complex query logic 𝗧𝗵𝗲 𝗿𝗲𝗮𝗹 𝗽𝗼𝗶𝗻𝘁: 𝗦𝗽𝗿𝗶𝗻𝗴 𝗱𝗼𝗲𝘀 𝗻𝗼𝘁 𝗳𝗼𝗿𝗰𝗲 𝘆𝗼𝘂 𝘁𝗼 𝘄𝗿𝗶𝘁𝗲 𝗲𝘃𝗲𝗿𝘆 𝗾𝘂𝗲𝗿𝘆 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝘄𝗮𝘆. 𝘈𝘯𝘥 𝘵𝘩𝘢𝘵’𝘴 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨 𝘢 𝘭𝘰𝘵 𝘰𝘧 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘦𝘳𝘴 𝘰𝘷𝘦𝘳𝘭𝘰𝘰𝘬.  • simple query → derived method  • custom query → @Query  • raw control → JDBC  • serious SQL work → jOOQ Knowing Spring is not just knowing JPA. It’s knowing 𝘄𝗵𝗶𝗰𝗵 𝗱𝗮𝘁𝗮 𝗮𝗰𝗰𝗲𝘀𝘀 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 𝗳𝗶𝘁𝘀 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗯𝗲𝘀𝘁. 𝗛𝗮𝘃𝗲 𝘆𝗼𝘂 𝗲𝘃𝗲𝗿 𝘂𝘀𝗲𝗱 𝗷𝗢𝗢𝗤 𝗶𝗻 𝗮 𝗦𝗽𝗿𝗶𝗻𝗴 𝗽𝗿𝗼𝗷𝗲𝗰𝘁? #Java #SpringBoot #SpringFramework #JOOQ #JPA #JDBC #SQL #BackendDevelopment #SoftwareEngineering #Programming #Database #Tech

Ever felt like SQL is doing more work than your actual logic? Writing queries… mapping results… handling connections… It gets repetitive really fast. What if you could just work with objects instead? That’s where 𝗢𝗥𝗠 (𝗢𝗯𝗷𝗲𝗰𝘁 𝗥𝗲𝗹𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗠𝗮𝗽𝗽𝗶𝗻𝗴) comes in. Instead of writing complex SQL queries, you interact with your database using Java objects. No more manually converting 𝗿𝗼𝘄𝘀 → 𝗼𝗯𝗷𝗲𝗰𝘁𝘀. ORM does it for you. Let’s simplify it Without ORM:  • Write SQL queries  • Execute them  • Map ResultSet to objects manually With ORM:  • Create a class  • Map it to a table  • Call methods like save(), findById() That’s it. Popular ORM frameworks we might know: 𝗛𝗶𝗯𝗲𝗿𝗻𝗮𝘁𝗲 (most widely used) 𝗝𝗣𝗔 (Java Persistence API – standard) Why developers love ORM:  • Faster development (less boilerplate)  • Focus on business logic, not SQL  • Automatic mapping between objects & tables  • Easy integration with Spring Boot But here’s the real insight ORM is powerful… but blindly using it can hurt performance. Sometimes, writing a custom query is still the better choice. So the goal isn’t to avoid SQL… It’s to use 𝗢𝗥𝗠 𝘀𝗺𝗮𝗿𝘁𝗹𝘆. Next time you call 𝘀𝗮𝘃𝗲() in your project, remember — there’s a lot happening behind the scenes. #CoreJava #JavaDeveloper #Spring #Framework #ORM #SpringBoot #SpringData #Hibernate #SoftwareDevelopment #SQL #BackEndDevelopment #MicroServices #Programming #aswintech #Database #BuildBetter 

🚀 Mastering Persistence in Spring Data JPA: persist() vs. merge() vs. save() Ever wondered which method to use when saving data in Java? Choosing the wrong one can lead to unnecessary SQL queries or even dreaded EntityExistsException errors. Here is the breakdown of the "Big Three": 🔹 1. persist() – The "New Only" Approach What it does: Takes a brand-new (transient) entity and makes it managed. It schedules an INSERT. Best for: Creating new records when you are sure they don't exist yet. Watch out: It will throw an exception if the entity is already detached or has an ID that exists in the DB. 🔹 2. merge() – The "Reconnector" What it does: Takes a detached entity (one that was loaded in a different session) and copies its state onto a new managed version. Best for: Updating existing records that were passed through different layers of your app (e.g., from a REST controller). Watch out: It creates a copy. You must use the returned object for further changes! 🔹 3. save() – The Spring Data Way What it does: A smart wrapper provided by Spring Data JPA. It checks if the entity is "new." If yes, it calls persist(); if not, it calls merge(). Best for: Most standard repository patterns. It’s the "safe bet" for 90% of use cases. Watch out: Because it checks state first, it might trigger an extra SELECT query to decide whether to insert or update. 💡 Pro Tip: If you are building high-performance systems with massive inserts, using persist() directly via the EntityManager can sometimes be more efficient than the generic save() method. Check out the infographic below for a quick visual cheat sheet! 📊 #Java #SpringBoot #JPA #Hibernate #SoftwareEngineering #BackendDevelopment

Stop Writing Infinite Repository Methods! 🛑 Use the Criteria Pattern How many times have you seen a Repository or DAO filled with methods like these? findByName(...) findByNameAndStatus(...) findByNameAndStatusAndDateRange(...) This is a maintenance nightmare. Every time the business asks for a new filter, you have to change your Interface and your Implementation. The Solution: Criteria Pattern (Specification) 🔍 The Criteria Pattern allows you to build database queries dynamically. Instead of defining every possible combination of filters beforehand, you create small, atomic "Criteria" objects that represent a single rule (e.g., PriceLessThan, IsActive). Why it changes the game for DB Ops: Dynamic Query Building: You can combine filters at runtime based on what the user actually selects in your UI. Clean Repositories: Your repository only needs one method: find(Criteria criteria). Decoupling: Your business logic defines what to search for, while the Criteria implementation handles the SQL/NoSQL specifics. DRY (Don't Repeat Yourself): Define the "Active Customer" logic once and reuse it across your entire application. How it looks in practice (Spring Data JPA / Hibernate example): Instead of a mess of parameters, you use a Specification API: Java public List<Order> getOrders(String status, Double minAmount) { return orderRepository.findAll( Specification.where(hasStatus(status)) .and(amountGreaterThan(minAmount)) ); } The Result? 📈 A codebase that is elastic. You stop coding "fixed" queries and start building a flexible filtering engine that grows with your product. Is it useful to you? Repost it to your network! ♻️ Do you use the Criteria Pattern in your DAL (Data Access Layer), or are you still sticking to traditional Query Methods? Let's talk about it! 👇 #DatabaseDesign #SQL #CleanCode #BackendDevelopment #SoftwareEngineering #CriteriaPattern #Programming

💡 𝐂# 𝐓𝐢𝐩: 𝐖𝐫𝐢𝐭𝐞 𝐭𝐚𝐥𝐥 𝐋𝐈𝐍𝐐 𝐪𝐮𝐞𝐫𝐢𝐞𝐬, 𝐧𝐨𝐭 𝐰𝐢𝐝𝐞 𝐨𝐧𝐞𝐬 - 𝐲𝐨𝐮𝐫 𝐟𝐮𝐭𝐮𝐫𝐞 𝐬𝐞𝐥𝐟 𝐰𝐢𝐥𝐥 𝐭𝐡𝐚𝐧𝐤 𝐲𝐨𝐮 Some developers write LINQ queries on a single line. It works, but once the query grows, it becomes unreadable fast. The fix is simple: go tall, not wide. 🔹 What is a "tall" LINQ query? It means breaking each LINQ operator onto its own line. One operator per line, aligned vertically. No horizontal scrolling, no squinting to find where the filter ends and the projection begins. 🔹 When does this matter? The moment you chain more than two operators. A .Where().Select() on one line is fine. Add .GroupBy().OrderBy().Take() and it falls apart immediately. Tall formatting also makes diffs cleaner in pull requests - each change shows up on its own line. 🔹 The trap Developers treat LINQ like a sentence and write it left to right. That habit comes from SQL, ironically - but even SQL uses newlines for each clause. Your LINQ query is no different. Treat each method call as its own clause. ✦ Put each LINQ operator on its own line, indented consistently ♻️ Repost to help your team write more readable C# code! 📌 Save this for your next code review Subscribe to my weekly .NET newsletter 🚀 https://lnkd.in/drjE3rjP Follow Remigiusz Zalewski for more daily .NET tips 👇 #csharp #dotnet #aspnetcore #efcore #linq #sql #softwaredeveloper #programming #webdevelopment #careergrowth #developer #coding #aspnet

When I first started with Spring Data JPA, this honestly felt like magic User findByEmail(String email); No SQL . No implementation. No query. And somehow… it worked. I used it for a long time before asking How is this actually possible? When I started with Spring Boot, I assumed this was just framework magic and I think many of us have felt the same. But that skips the most interesting part. It is not magic. It is a parser. Spring treats this method name: findByEmail() as a mini query language. Yes — the method name itself. Internally, Spring Data uses a parser called PartTree to read it. It breaks it into meaning like - * find → create a select query * By → start parsing criteria * Email → match an entity property If your entity has - private String email; Spring can derive a query from the method name.That is called query derivation using naming conventions.And this is where it gets deeper.Spring does not directly generate SQL.It first derives JPQL.Then Hibernate converts JPQL into database-specific SQL. This getSomeUserStuff() does not work. Because the parser does not understand it. But this findByEmailAndStatus() works because it follows a grammar.That is not just convention. That is a contract. And one detail many of use miss - Spring validates these derived queries at startup. Not later. So if you write: findByEmailAddress() but your entity does not have - emailAddress , your application can fail fast during startup. That is intentional framework design. Sometimes the most elegant engineering is hiding inside the APIs we use every day. #SpringBoot #Java #JPA #Hibernate #BackendDevelopment

One loop. 500MB of memory. One string that should have been 2KB. The task was simple. Build a CSV export from a list of records and return it as a response. The code looped through every record and kept appending to a string using something like: result = result + row + “\n” Clean. Readable. Completely harmless. In development with 200 records, it ran instantly. In production with 800,000 records, the server started choking. Memory climbed to 500MB for a single request. Response times stretched to 40 seconds. Other requests started failing because there was no memory left. The code had not changed. The data had. Here is what was actually happening. Strings are immutable. Every time you append to a string, a new string is created in memory. Loop 1 creates a string of 1 row Loop 2 creates a new string of 2 rows Loop 3 creates a new string of 3 rows The previous strings don’t disappear immediately. They stay in memory until garbage collection runs. 800,000 iterations. Hundreds of thousands of intermediate strings. Massive memory pressure for something that should have been simple. The fix was one line. Use a StringBuilder or equivalent. Append to a buffer. Build the string once at the end. Memory dropped from 500MB to under 5MB. Response time dropped from 40 seconds to under 2 seconds. Same output. Same logic. Completely different performance. This is the kind of problem that never shows up in development. Because the issue is not the code. It is the combination of code and data scale. The most dangerous code is not complex code. It is simple code that looks too innocent to question. #SystemDesign #MemoryManagement #Java

Your database is not the problem. Your queries are. A slow application doesn't always mean you need a bigger server or a fancier cache. Most of the time, the bottleneck is sitting right there in a query nobody questioned. Spring Boot, or ORMs in general makes data access so easy that it's tempting to just let JPA handle everything. And it will, until it won't. The classic traps: N+1 queries. You fetch a list of 100 orders. Then for each order, JPA quietly fires another query to get the customer. That's 101 queries instead of 1. Feels fine in dev with 10 rows. Falls apart in prod with 100,000. Fetching everything when you need one field. findById() returns the full entity when the screen only needs a name and a date. Multiply that by thousands of requests and you're moving data for no reason. No pagination. findAll() sounds harmless. Until your table hits 2 million rows and you just loaded all of them into memory. Ignoring indexes. A query that runs in 3ms on 1,000 rows runs in 4 seconds on 1,000,000 if the column isn't indexed. The code didn't change. The data did. Use @Query when the query matters. Use projections or DTOs to fetch only what you need. Add @EntityGraph to control fetching explicitly. Paginate by default. And always look at the actual SQL being generated. What Hibernate writes is not always what you'd write. Performance issues are rarely mysterious. They're usually a query doing too much, too often, or too blindly. Read your queries like they cost money. Because in production, they do ! #SpringBoot #Java #DatabasePerformance #BackendDevelopment #SoftwareEngineering #CleanCode #JPA #Hibernate #TechTips #WebDevelopment

🚀 DAY 16 — @PathVariable, @RequestParam, @RequestBody ✅ 1. CLEAR CONCEPT (VERY IMPORTANT) 👉 These 3 are used to get data from client AnnotationFrom where data comes@PathVariableURL path@RequestParamQuery parameter@RequestBodyRequest body (JSON) 🧠 SIMPLE UNDERSTANDING 👉 3 ways client sends data: URL → /users/1 → PathVariable Query → /users?id=1 → RequestParam Body → JSON → RequestBody 💻 EXAMPLES (VERY IMPORTANT) 🔹 1. @PathVariable @GetMapping("/users/{id}") public String getUser(@PathVariable int id) { return "User id: " + id; } 👉 URL: /users/1 🔹 2. @RequestParam @GetMapping("/users") public String getUser(@RequestParam int id) { return "User id: " + id; } 👉 URL: /users?id=1 🔹 3. @RequestBody @PostMapping("/users") public String addUser(@RequestBody String name) { return "User " + name + " added"; } 👉 Body (JSON): { "name": "Ashish" } 🔄 FLOW (IMPORTANT) 👉 Client → sends data → Controller receives → Method executes 🎯 INTERVIEW QUESTIONS (MUST 🔥) ❓ Difference: @PathVariable vs @RequestParam? 👉 PathVariable → part of URL 👉 RequestParam → query parameter ❓ What is @RequestBody? 👉 Takes JSON data from client ❓ When to use @PathVariable? 👉 When ID is part of URL ❓ When to use @RequestParam? 👉 For optional/filter values ⚡ BEST PRACTICES ✔ Use PathVariable for IDs ✔ Use RequestParam for filters/search ✔ Use RequestBody for POST/PUT 💡 FINAL UNDERSTANDING 👉 Path → URL data 👉 Param → Query data 👉 Body → JSON data 💬 Which one confused you — Path or Param? Day 16 done ✅ #SpringBoot #Java #BackendDevelopment #LearningInPublic #30DaysOfCode #Developers

4 things nobody tells you about JPA's @PrePersist and @PreUpdate: 1. @PreUpdate only fires if Hibernate actually issues an UPDATE. No field changed = no callback. 2. JPQL bulk updates bypass callbacks completely. Your timestamps won't refresh. 3. Don't call other repositories inside callbacks. That's how you get mysterious exceptions at 2 AM. 4. For pure audit fields, @EnableJpaAuditing is cleaner. Save @PrePersist for actual domain derivation, slugs, counts, computed fields. Full breakdown with code examples 👇 https://lnkd.in/guSfFfVV #Java #SpringBoot #JPA #Hibernate