Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with JPA/Hibernate

stemlaur.com

Post reply on HN
Print view View original

31–40 of 195 posts

Re: Problems with JPA/Hibernate

#31

Post by jacques_chester »

dale_glass wrote: post #25

I disagree with this bit: A User can be considered unique in one context by its email address, or by its social security number Personally, I'm a fan of giving everything a random UUID, because it's more flexible. It's random and impossible to guess, it scales well because there's no central bottleneck like with an autoincrement, and it's future proof and flexible. What happens when the user changes the email address…

> What if the social security number changes, because it was wrong or because it actually changes?

What if the user doesn't have an SSN? What happens if they have one but lawfully refuse to provide it? What happens when you ask for and SSN from a US citizen who is also a European citizen? What happens when your database leaks?

In general, relying only on natural keys is a nightmare. Double nightmare if it's PII. Natural keys only work if you are flawlessly omniscient about the domain. And you aren't.

Re: Problems with JPA/Hibernate

#32

Post by rakoo »

Areading314 wrote: post #2

What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point

It works ? I'll argue that 90% of problems solved by SaaS today could be solved by any of the usual suspects of languages. What matters more is the architecture you choose. Choice of language is mostly a convenience choice, based on how comfortable you will be editing software in that language (that includes not only your proficiency, but also the availability of libraries and frameworks to help you)

Re: Problems with JPA/Hibernate

#33

Post by jacques_chester »

AaronFriel wrote: post #17
ssijak wrote: post #13

Earlier quoted context omitted.

TechEmpower Web Framework Benchmarks would like to disagree with you.

I don't think those are particularly realistic workloads, as they don't involve substantial amounts of working with in-memory data. Which of the TechEmpower benchmarks uses an ORM? Before I finished drafting my comment I did have a sentence like this, which I removed, "Barring obscene amounts of optimization", so yes, some web servers like netty and jetty have gotten to a level of good performance in terms of handlin…

> Which of the TechEmpower benchmarks uses an ORM?

There are two: single query and multiple query.

Re: Problems with JPA/Hibernate

#34

Post by santiagobasulto »

dale_glass wrote: post #25

I disagree with this bit: A User can be considered unique in one context by its email address, or by its social security number Personally, I'm a fan of giving everything a random UUID, because it's more flexible. It's random and impossible to guess, it scales well because there's no central bottleneck like with an autoincrement, and it's future proof and flexible. What happens when the user changes the email address…

I'm from Argentina and we have something similar to a SSN, we call it DNI (Documento Nacional de Identidad). You wouldn't believe how many duplicate DNIs we have, it's crazy.

So yes, I agree with you, I always use a random UUID as ID.

Re: Problems with JPA/Hibernate

#35

Post by tarkin2 »

Daishiman wrote: post #15
api wrote: post #9

From my experience ORMs are good time savers when you have relatively simple query needs, but fall down when things get really complex.

"Really complex" means getting down to 6 or 7 joins for your typical SQLAlchemy or Django ORM query. These sorts of queries comprise 5% of my queries, tops. Seems like a fair tradeoff.

I have one of those queries. It's the most important in the database sadly. As django bloats and bloats the table space, over the years, more and more do I need those queries, and slower and slower becomes my app.

Re: Problems with JPA/Hibernate

#36

Post by SahAssar »

Scarbutt wrote: post #19
buster wrote: post #3

Earlier quoted context omitted.

A huge developer base and eco system? What specifically, can't be achieved in Java, that you think node is needed for?

Rendering Javascript.

There is https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) and https://en.wikipedia.org/wiki/GraalVM. The latter of those is the second fastest js server runtime (es4x) according to techempower benchmarks: https://www.techempower.com/benchmarks/#section=data-r20&hw=...

I haven't tried any of those, but saying the JVM can't run JS is not true.

Re: Problems with JPA/Hibernate

#37

Post by harryvederci »

The only positive experience I've had with it was in a small application with a not-so-complex DB which was created entirely through Liquibase.

In large enterprise projects, I've always had to create custom SQL statements at some point, at which point I'd rather do everything in SQL. Otherwise, you have to know JPA/Hibernate and SQL, which (in my opinion) defeats the purpose.

Re: Problems with JPA/Hibernate

#38

Post by echelon »

jacques_chester wrote: post #31
dale_glass wrote: post #25

I disagree with this bit: A User can be considered unique in one context by its email address, or by its social security number Personally, I'm a fan of giving everything a random UUID, because it's more flexible. It's random and impossible to guess, it scales well because there's no central bottleneck like with an autoincrement, and it's future proof and flexible. What happens when the user changes the email address…

> What if the social security number changes, because it was wrong or because it actually changes? What if the user doesn't have an SSN? What happens if they have one but lawfully refuse to provide it? What happens when you ask for and SSN from a US citizen who is also a European citizen? What happens when your database leaks? In general, relying only on natural keys is a nightmare. Double nightmare if it's PII. Natu…

I want to print this comment and frame it.

Re: Problems with JPA/Hibernate

#39

Post by tarkin2 »

api wrote: post #9

From my experience ORMs are good time savers when you have relatively simple query needs, but fall down when things get really complex.

And time. Let's not forget time.

Years of Django's ORMs has given our app over a hundred tables. Complex and /fast/ queries are next to impossible.

Django's ORM made app development lightening quick for the first developers. And impossible for the ones fives years later.

Re: Problems with JPA/Hibernate

#40

Post by yukinon »

dale_glass wrote: post #25

I disagree with this bit: A User can be considered unique in one context by its email address, or by its social security number Personally, I'm a fan of giving everything a random UUID, because it's more flexible. It's random and impossible to guess, it scales well because there's no central bottleneck like with an autoincrement, and it's future proof and flexible. What happens when the user changes the email address…

> Personally, I'm a fan of giving everything a random UUID, because it's more flexible

Unless of course, you're using a relational database like OP and incur a performance hit from using a UUID as your primary key. Additionally, they're not sortable like autoinc id's.

I've always wanted to try out Twitter's Snowflake ID [1] algorithm to get around this, but it requires requires using something like Zookeeper. I've seen some people on the net talk about UUIDv6 being sortable by time, but there's still the potential performance hit of index size.

While I'm bringing this up I've never actually tested how slow PK UUIDv1's are and at what magnitude their performance hit becomes noticeable.

[1] https://blog.twitter.com/engineering/en_us/a/2010/announcing...

Post reply on HN