Problems with JPA/Hibernate

Post by sabellito » Mon, Apr 12, 2021, 5:47 AM UTC

eitland wrote: post #108

doctor_eval wrote: post #52

In my extensive experience managing teams using JPA ORMs including Hibernate and EclipseLink, you not only get to learn the unavoidable details of your target database’s SQL, but also the complex, non-obvious side effects - especially caching interactions and performance edge cases - of the ORM as well. You also get to learn two distinct but similar query languages (one of which you can’t use anywhere else but Java).…

Generally you should use the right tool for the job and that might be something else. This however: > You get to throw away all the semantics built into the database structure, including knowledge about indexes, suggests you either don't know JPA very well or your writing is a bit sloppy. Please avoid making sweeping generalisations about tools that save hundreds (or al lot more) of hours of programmer tools just bec…

Post by doctor_eval » Mon, Apr 12, 2021, 5:54 AM UTC

tablespoon wrote: post #107

doctor_eval wrote: post #90

Earlier quoted context omitted.

JPA is OK (but only OK) if you don’t have anything other than JPA accessing the database but in our largest application (1,000+ tables) this was never going to be the case. We had plenty of experience with database design, that’s not the problem. But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE stat…

> But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE statement for each child row. I’m sure there are loads of good reasons why it did that, but it’a not something that you’d even consider in pure SQL. IIRC, it does that if you use Lists instead of Sets. https://dzone.com/articles/best-performance-pra…

Post by Ygg2 » Mon, Apr 12, 2021, 6:10 AM UTC

tablespoon wrote: post #107

doctor_eval wrote: post #90

Earlier quoted context omitted.

JPA is OK (but only OK) if you don’t have anything other than JPA accessing the database but in our largest application (1,000+ tables) this was never going to be the case. We had plenty of experience with database design, that’s not the problem. But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE stat…

> But we found even in simple applications with a dozen tables, the generated SQL was suboptimal. For example, to delete the children of a parent row resulted in a DELETE statement for each child row. I’m sure there are loads of good reasons why it did that, but it’a not something that you’d even consider in pure SQL. IIRC, it does that if you use Lists instead of Sets. https://dzone.com/articles/best-performance-pra…

    Person { 
       id: Integer, 
       name: String
    }

Post by Zardoz84 » Mon, Apr 12, 2021, 6:26 AM UTC

agilob wrote: post #41

vips7L wrote: post #6

This article is... Questionable at best. I don't think any of this is an argument against JPA, except that the author doesn't like how it works? I also suspect the author doesn't know hibernate that well. For instance selecting just the fields you need is relatively simple with JPQL: SELECT i.url FROM Image i WHERE i.id = ...

JPA and Hibernate make it very easy to use it incorrectly, its almost like they promote bad SQL queries and ideas. They let users of database connection to write Java-first database queries, when database query should be database first, it's just way too easy to abuse it and get too much data, too many columns and JOINs. Developers look like JSON looks like, what we send to browser, what formatting it has, validation…

Post by watwut » Mon, Apr 12, 2021, 6:57 AM UTC

eitland wrote: post #109

agilob wrote: post #41

Earlier quoted context omitted.

JPA and Hibernate make it very easy to use it incorrectly, its almost like they promote bad SQL queries and ideas. They let users of database connection to write Java-first database queries, when database query should be database first, it's just way too easy to abuse it and get too much data, too many columns and JOINs. Developers look like JSON looks like, what we send to browser, what formatting it has, validation…

> Hibernate is popular because we don't need to learn SQL to get needed data, but it's also super hard to get it right and don't do something stupid by accident. I think this is plain wrong, or I might have been very lucky with who I work with: if anything I think most people I work with learned JPA or other ORMs long after learning SQL.