5 ms·
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 writ
by agilob 6y ago
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 and size of JSON data, as it's easy to monitor and trim.
Can't say the same about Hibernate. How the hell even hibernate caching works? Why even are there 2 levels of Hibernate cache? It's too easy to create and abuse transactions. Dirty-checking is JUST WAYYYY TOOO EAZY TO ABUSE. not calling, using setter of an instance shouldn't update in database by default omg, It shouldn't be possible for transactions to leak outside some easily specified scope - I've seen one project where transaction leaked to Jackson!! Jackson was calling getters on fields and executing DB queries. JSON ended up as 2.6Mb instead list of 10 fields.
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.
If in any doubt, refer to JOOQ - it's the SQL-oriented ORM for Java.
- vips7L 6y ago> How the hell even hibernate caching works? Why even are there 2 levels of Hibernate cache? https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#caching https://docs.jboss.org/hibernate/stable/orm/userguide/html_s... > using setter of an instance shouldn't update in database by default omg This doesn't happen.. the database won't update until you ask the entity manager to persist the entity. > I've seen one project where transaction leaked to Jackson!! Jackson was calling getters on fields and executing DB queries. JSON ended up as 2.6Mb instead list of 10 fields. I suspect you might not agree, but JPA lazy loading is one of the easiest concepts to understand. However, I'd argue that leaking your database models to the view is a mistake to begin with and said application is already incorrect. > If in any doubt, refer to JOOQ - it's the SQL-oriented ORM for Java. Both the author/maintainer of jOOq and Hibernate agree that each has their place. I really am amazed at developers that don't take the time to learn about the tools they use.
- eeperson 6y ago> This doesn't happen.. the database won't update until you ask the entity manager to persist the entity. Doesn't this happen through automatic dirty checking?
- vips7L 6y agoNo calling a setter on an Entity doesn't automatically issue an sql UPDATE query. You need to ask the EntityManager to merge or persist the entity and it's changes. Obviously JPA knows what fields were updated via dirty checking.. that's almost half the point of an ORM.
- eeperson 6y agoI'm not talking about "dirty checking". I'm talking about "automatic dirty checking". Take for example this code I got from this article[1]: SessionFactory sessionFactory = HibernateUtil.getSessionFactory(); Session session = sessionFactory.openSession(); Transaction tx = session.beginTransaction(); Person person = session.load(Person.class, 2); //loads Person object for id 2 person.setAge(32); tx.commit(); session.close(); HibernateUtil.closeSessionFactory(); It results in an updated age for the person in the DB. However, EntityManager was never directly notified about the change in the person object. [1] - https://learnjava.co.in/automatic-dirty-checking-in-hibernate/ https://learnjava.co.in/automatic-dirty-checking-in-hibernat...
- vips7L 6y agoThat's because JPA isn't involved here. It's directly using hibernate api's and not sticking to the standard which is what I was talking about.
- eeperson 6y agoHave you verified that? I'm pretty sure that occurs using the JPA API and Hibernate. I'm not sure if other JPA providers do this as well.
- eitland 6y ago> 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.
- watwut 6y agoYeah, I really dont know anyone in real life who would claim or expect developers to not know SQL just because hibernate is used. Hibernate is how to get data into Java. And we still have database scripts, migrations to new versions and what not.
- deleted 6y ago[deleted]
- morelisp 6y agoYou have been lucky. Part of our hiring test (intentionally) does something which is trivial to get correct if you know SQL but also easy to get racey with Hibernate. About 4/5 of applicants get it wrong and maybe 2/5 don't know how to fix it when we show them they problem. (Spring devs with 1-5 years experience in web APIs and reporting.)
- Zardoz84 6y ago> not calling, using setter of an instance shouldn't update in database by default omg, It shouldn't be possible for transactions to leak outside some easily specified scope - I've seen one project where transaction leaked to Jackson!! Jackson was calling getters on fields and executing DB queries. JSON ended up as 2.6Mb instead list of 10 fields. I saw a similar problem with some old codebase where I work. There is some Velocity templates that shows information stored on database entities (yeah... bad idea). And sometimes, we got some mysterious errors about transaction closed. Well... Results that Velocity calling the getters of these beans, can trigger a JPA/Hibernate query to get some additional data that has been loaded before. And this could happens after we close the database transaction.