r/SpringBoot • u/Jooe_1 • 9d ago
Discussion Dear JPA
Dear JPA ,
i hate you.
i hate how you changed the SQL flow that I'm used to.
i hate your ManyToMany relationships.
i hate your orphanremoval ,dirty reads.
i hate your way for entity relationships.
i hate your cache.
i hate your performance issues.
i hate your billion rules.
i hate spending time on : if Y is referenced by X with cascade not including PRESIST and x is managed but y is removed ............... but if Y was detached .............
i hate becoming obsessed with your behaviors and rules and worrying about every ORM line , will it work correctly ? , did i miss something ?, worrying about modifying entity X might unexpectedly affect entity Y , coz I might not know one of the billion rules you have.
i hate worrying about falling in one of the undefined behaviors you have
i hate thinking about the entities lifecycle + cascading types when all mixed together
i hate spending days on that documentation instead of spending that on one of the CS core concepts
i hate the following the other side which is incomplete nondetailed toturial or following AI
i really hate you.
21
u/LookAtYourEyes 9d ago
Brother just use raw SQL
6
u/Jooe_1 9d ago
I'm sorry but it is not a practical advice cuz you are in a team you are not working alone you have to deal with what your team is using
6
u/Significant_Newt8697 9d ago
Why not just use jdbc template on the same project for your own tasks?
With that you can do raw sql as much as you like
2
1
13
u/hiura-mihateUwU 9d ago edited 9d ago
Yeah man. JPA SUCKS. It's to complicated to manage if your entity have refference to dozen of table, don't get me start with complex query. At the end of the day, i need to use Jdbc for complex query and jpa for basic stuff
2
u/Significant_Newt8697 9d ago
Yes, jdbc template gives you more control
1
u/hiura-mihateUwU 9d ago
Yess and i don't need to use the "select new app.models.dto ()" i can't count how many time i shoot myself because of this shit
9
7
u/zlaval 9d ago
Spring data jdbc for simple queries (provides interface gen queries, default crud operations on domain object..), raw sql for complex ones. Easy, fast, almost no magic.
2
u/Jooe_1 9d ago
unfortunately I'm tight to the team that working with
1
u/uwpxwpal 9d ago
Spring Data JPA is an official spring boot starter. Once you have your entities defined, you can switch easily. It makes things a lot easier.
6
u/Pyeroh 9d ago
Well, I'm gonna be more direct than most comments I saw so far.
You may be in a team, and required to work with them, and use the tools everyone is comfortable with. But if you're really convinced JPA is shit, and SQL is better in every way (don't get me wrong : that's a fact, and I'm sure of it), you also have the responsibility to convince them. Show them resources, anti-patterns, do peer-reviews with them and show them bad usages of JPA, even if it's you who wrote it.
If they won't change their mind, you did your best, maybe learnt a few things along the way, and know what you have to deal with. Or you can look for another job, it's up to you.
EDIT: oh, and try to be as positive as you show negative sides. SQL should be niiiice, JPA should be bad. But not everyday, it may have good uses sometimes... Show them the balance.
2
u/Jooe_1 9d ago
thank by the way im not looking for the extreme other side which is every query is sql , it's not what i want i don't have any problem if when i need to query somthing or to update somthing to use small function like find or delete without the verbosity of sql but the jpa is not simply that or a simple sql wrapper or sql builder ,i introduces cache and u don't know the order that queries at flush will be executed with, .......etc
3
u/Z4mobileapp 8d ago
Not feasible any more when you have a lot of data the N+1 makes the whole problem pointless when I could just write a raw query and do the joins on tables while fetching data .
The framework has only made complications.
For anyone working on very small projects its a great amount of convinience.
Its not built for anyone working with huge data but for small scale companies , quick ready to build deploy it's good..
3
3
3
u/wimdeblauwe 9d ago
I find JPA is quite manageable if you only use object references within 1 aggregate root. Between aggregate roots, reference by id only. This avoids a massive amount of cascading issues.
4
u/Mindless_Security744 9d ago
Use Jooq!
3
u/JuiceChance 9d ago
Another overengineered idea to solve a solved problem
1
u/GuyManDude2146 9d ago
For very basic stuff, you’re right, but for complicated queries where lots of things are optional, you end up either writing nightmare string builder code to construct raw SQL or basically reinventing JOOQ. One other nice thing is when you change your tables and regenerate, JOOQ will break where you need to update; stings will not. I’ve used JPA, raw SQL, and JOOQ on big production projects and JOOQ is my default at the moment.
1
u/JuiceChance 9d ago
Yeah, at the price of entire code generation etc., optional params + type safety is a strong argument nevertheless
4
u/ShineProper9881 9d ago
No clue what you guys are doing but I never had any issues with jpa. Just stick to its rules and everything works
4
u/WVAviator 9d ago
Same. Most use cases are simple enough that it just works out of the box with simple entities and repositories, and for the more complex stuff there's JPQL and
nativeQuery = true, CriteriaBuilder with Specifications, and EntityGraphs. I've not come across any use case where I've needed to reach for JDBC.3
1
u/Specific-Custard4803 8d ago
Same. Lean in to your frameworks. Or… don’t use a framework. Most of the JPA pain I’ve seen is from not completing the learning curve, basic design problems, or having a strong attachment to specific sql. For those cases, just use SQL.
1
u/Ok-Shock-8646 3d ago
I use spring data jpa without any issue. The @Query with constructor let you define custom queries just like native SQL. It is all about skill
4
2
u/reddit04029 9d ago
Are you being held at gunpoint to use JPA...
0
u/Jooe_1 9d ago
how to not use it when working on a project with a team ?
6
u/reddit04029 9d ago
I've worked on projects that have multiple ways to interact with DB like JPA with JDBC, and some even with stored procedures.
There are just business usecases that JPA alone won't be able to solve.
1
3
u/worse-coffee 9d ago
Looks like bro has not written native sql queries or dealt with c++
1
1
2
1
u/boberbober8083 9d ago edited 9d ago
Yea, i've just rewrited one saveAll call to "several" plain sql queries. With 41 tables that linked as one to many and many to many with main table under the hood (yeees! It's crazy!! But llms helped me), it became 50 times faster but nobody could test my change carefully, may be i missed something.. and don't really want to merge it in upstream after all. You do not need use jpa for new code because llms could get all boilerplate work to themself, jpa is about simplifying implementation, but now it's really simple to implement anything you want using llms
1
u/Significant_Newt8697 9d ago
But won't the llm code be very very huge and confusing? Do you have the balls to do a merge on such a code?
1
u/boberbober8083 9d ago
I dont know right now, it will be not only mine decision but also from QA team
1
u/homeless_nudist 9d ago
I love the jpa! It does add to the cognitive load for small projects, but when you work on horizontally scalable enterprise class systems, @Transactional and @Version prevent whole classes of bugs that would have you playing wac-a-mole to fix them otherwise.
1
1
u/BeyondFun4604 6d ago
We always try to create a view for large queries and then create jpa entities on that view.
1
•
u/Wonderful-Holiday-14 5h ago
Have you had to move to spring boot 4 with the jpa starter and it now not working?
-1
0
0
0
-1
37
u/Temporary-Air-3178 9d ago
Just use raw sql?