DEV Community

Karan Sahani
Karan Sahani

Posted on

Spring Boot CRUD Generator v1.1.0 — JPA Relationships, Done Right

🔗 Plugin link: https://plugins.jetbrains.com/plugin/29476-spring-boot-crud-generator

I shipped an update to my IntelliJ plugin that fixes something subtle but critical — the way generated Spring Boot code handles JPA relationships.

The plugin has crossed 1200+ downloads, and the feedback pattern was clear:

Everything works fine… until you add relationships.


❌ The Real Problems

1. LazyInitializationException at runtime

Generated mappers were doing this:

entity.getPosts().stream()...
Enter fullscreen mode Exit fullscreen mode

Works in tests.
Breaks in production (outside transaction scope).


2. null IDs in API responses

DTO generator was skipping id completely.

So every response looked like:

{ "id": null, "name": "java" }
Enter fullscreen mode Exit fullscreen mode

Which makes your API… basically unusable.


3. Mapper calling setters that didn’t exist

Inverse @OneToMany relationships were not generated in DTOs.

Result:

  • Mapper tries → dto.setPostIds(...)
  • DTO doesn’t have it → ❌ compile error

✅ What v1.1.0 Fixes

✔ ID is always present

  • Included in DTO
  • No @NotNull
  • Marked as NOT_REQUIRED
  • Server-controlled

✔ Safe toDto() mapping

dto.setId(entity.getId());
Enter fullscreen mode Exit fullscreen mode

First line. Always.


✔ Collections → null (intentional)

dto.setPostIds(null);
Enter fullscreen mode Exit fullscreen mode

Why?

  • null = not loaded
  • emptyList() = loaded but empty ❌ misleading

Also avoids LazyInitializationException entirely.


✔ Single relationships → ID only

dto.setUserId(entity.getUser().getId());
Enter fullscreen mode Exit fullscreen mode

No nested objects.
No recursion.
Frontend-friendly.


✔ Import system fixed

No more garbage like:

com.app.entity.entity.User
Enter fullscreen mode Exit fullscreen mode

🧠 Design Philosophy

Most generators try to map everything.

That’s the root problem.

This update follows a stricter rule:

  • Don’t trigger database access in mappers
  • Don’t assume relationships are loaded
  • Don’t generate code that only works in demos

🎯 Result

You get:

  • Predictable API responses
  • No lazy loading crashes
  • DTOs that always match mappers
  • Code that actually survives real projects

🙌 Final Thought

This isn’t a flashy release.

It’s a correctness upgrade.

The kind that saves hours of debugging later.


If you’re already using the plugin — update it.

If not — now it’s finally safe to use in real-world projects.

Would love feedback 👇

Top comments (1)

Collapse
 
buildbasekit profile image
buildbasekit

This is a strong update. You fixed the stuff that actually breaks in real projects.

  • The null vs empty decision is spot on. Most people get this wrong
  • Mapping only IDs for relationships keeps things predictable and avoids recursion mess
  • Good call on not triggering lazy loads inside mappers

One thing to watch:

  • Returning null for collections can confuse frontend teams if not documented clearly

Overall, this is the right direction. Less magic, more correctness.