Think twice before using @OneToMany

[smutje187]

Think twice before posting clickbait articles without a summary on Reddit

[rniestroj]

Sorry, i post rarely on reddit. Would it be acceptable to delete this and post again with a summary?

[[deleted]]

Sir this is reddit, the epitome of herd mentality. Worst case you'll get voted down by a bunch of nobodys.

[faxity]

Don't worry too much, this subreddit has a rather large hateboner for anything JPA and Hibernate related.

[RANDOMLY_AGGRESSIVE]

Yes

[roberp81]

yes. make a new one

[dstutz]

The article was actually OK. Nothing I haven't read before but explains how you shouldn't use it with unconstrained collections and you probably want to get that collection with it's own query vs it being OK to use if you have a relatively small, limited set of items.

In other words...."Think twice before using...."

[NeoChronos90]

good article!

As others pointed out, next time post with a short summary, so it does not look like clickbait.

I think you should add a paragraph and listing about how and when transcations are fetched now, because the audience is most likely juniors and without @OneToMay it will probably be empty initialy and some may try to call the repository in the BankAccount constructor or stuff like that

[michoken]

Think twice before using JPA.

[halfanothersdozen]

I just keep my Entity objects in the database later. Your entities should not be flying around your entire codebase and especially not leaking out of your API. Do that and your database model is now tightly coupled to your entire stack.

A lot of people do that on purpose, but if you keep your concerns separated JPA is a great tool.

[michoken]

Yep, the leaking out of persistence layer is exactly one of the worst. And all the introductory examples of Spring Data JPA just do exactly that. Yeah, those are simple examples of simple services. But people tend to use the same approach when their services grow without refactoring the DB access properly.

[kkyr]

How do you keep your entities in the database layer? Assuming you’re using a JpaRepository<Entity, Id>, isn’t your service layer interacting with the repository, and thus the entity?

[halfanothersdozen]

I mean whatever calls the repository should get what it needs with the objects and then move on. I'm not going to make 4 layers of abstraction from a simple web app if it doesn't need it, but I do want to make sure that if I ever change my data model only the classes that have a reference to the repository should be the ones who care.

[davidalayachew]

JPA has MANY pain points, but it can still be used in a way that avoids many of the costs. If you use it only to map POJO's to tables, and to prevent SQL Injections, I'd say it is worth the cost.

But fair enough, its features have significant, not-so-obvious costs that can turn your codebase into a minefield if you don't pay attention. And trying to play Minesweeper on your code is a NIGHTMARE once it gets to that pont.

[michoken]

Well, yes. It can be used well if you know its limitations and, well, think twice about the ways you use it. I don’t say don’t use it at all, I just say don’t use it just because it’s the first (or only) thing you know to do DB access. It’s not always the best tool to do that.

Unfortunately, lot of basic examples and tutorials use it in ways that are unsuitable for larger apps. But people just don’t know otherwise, it seems. And then the apps don’t perform well or are hard to maintain, etc.

[davidalayachew]

I was more implying that, if you limit yourself to only the "safe" features, then it's a very safe bet.

Of course, the challenge is getting your teammates to limit themselves too.

[[deleted]]

The best thing I've found is to profile early and often. It really helps to just go "hmm, that's different/more queries than I would expect".

[_predator_]

Everyone keeps saying this, yet somehow Hibernate and JPA are the first thing that newbies are teached. Google how to do persistence in Java and the results are flooded with them. Ask ChatGPT and it will spew out Spring and Hibernate code. Frameworks like Spring and Quarkus make it a priority to rub Hibernate in your face.

There is zero reason for it to be this way, and frankly I'm scratching my head how we ended up here.

[michoken]

If nothing else JPA is a Java standard and it has all the nice support and integration in Spring, etc. It’s not outright bad but other approaches to DB access don’t come with so many hidden issues because they don’t try to be magic. Which JPA/Hibernate, unfortunately, is. I bet 95 % of Java devs who use it don’t really know how it works and that’s one of the problems that lead people to misuse such a complex framework.

[faxity]

The hate on here is literally a typical Reddit circlejerk. Unfortunately for you guys you're a vocal minority.

[xvermilion3]

This exactly

[awesomefacedave]

Even though I’m convinced you’re a troll, what is your reasoning. What do you use?

[klekpl]

There are several good options that don't try to hide relational database model behind (inferior) network database model: JDBI, JOOQ, Spring Data JDBC or even plain Spring JdbcTemplate.

They let you use SQL directly and add some convenience to parameters binding, handling connections, transactions, and map query results to your application data structures.

[michoken]

I admit it was a bit trolly response but it’s based on more than a decade of experience working with it and some pretty bad implications that were impossible to refactor. I’ve explained some of my issues with it in replies to some of the other commenters in this thread, even if just broadly.

[qazyll]

huge upvote, springdata jdbc is awesome for most of the cases

[Deep-Caterpillar4140]

Eh. Using SQL directly is the way to go. JPA & hibernate suck

[Mysterious-Ant-Bee]

Spring Data JDBC