3 ms·

> 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/

by 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 ago
  No 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 ago
    I'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 ago
      That'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 ago
        Have 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.
      - eeperson 6y ago
        I'm almost certain this occurs with Hibernate as the JPA provider. I haven't tried this with other JPA providers but as far as I can tell from tutorials[1], stack overflow posts[2], and the JPA documentation[3], this is the default for JPA as well. [1] - https://www.objectdb.com/java/jpa/persistence/update https://www.objectdb.com/java/jpa/persistence/update [2] - https://stackoverflow.com/a/8307991 https://stackoverflow.com/a/8307991 [3] - https://docs.oracle.com/javaee/6/tutorial/doc/bnbqw.html#bnbrf https://docs.oracle.com/javaee/6/tutorial/doc/bnbqw.html#bnb... EDIT: Oops I accidentally replied to this twice
    - watwut 6y ago
      That is because "session.load(Person.class, 2)" line literally says "and track changes" - as article says. That is not how Hibernate or JPA is used normally. It is going out of standard way to achieve the thing you complain about.
      - eeperson 6y ago
        > That is because "session.load(Person.class, 2)" line literally says "and track changes" - as article says. I'm aware that that what occurs. That is my point. I'm responding to the previous posts statement "No calling a setter on an Entity doesn't automatically issue an sql UPDATE query". This is an example where calling a setter causes an update query to be run. > That is not how Hibernate or JPA is used normally. It is going out of standard way to achieve the thing you complain about. What about this not not how Hibernate and JPA are used normally? Are you saying that setters are not normally used? Do you mean that people normally call update or merge to persist an Entity? If so, I agree that is what people normally do. However, when people do that they tend to accidentally introduce bugs. Usually this occurs when they update an entity and then do some validation on it. When the validation fails they think they can avoid sending he changes to the DB by doing nothing. However, that isn't true. They have to manually evict the entity from the session to prevent that from happening.
  - deleted 6y ago
    [deleted]
  - alserio 6y ago
    If you have a managed instance of an entity, like something returned by a find or a query, calling a setter will modify its state and the state change _will_ be detected and persisted automatically on the next flush, without explicit persist or merge.

by vips7L 6y ago

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 ago
No 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 ago
  I'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 ago
    That'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 ago
      Have 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.
    - eeperson 6y ago
      I'm almost certain this occurs with Hibernate as the JPA provider. I haven't tried this with other JPA providers but as far as I can tell from tutorials[1], stack overflow posts[2], and the JPA documentation[3], this is the default for JPA as well. [1] - https://www.objectdb.com/java/jpa/persistence/update https://www.objectdb.com/java/jpa/persistence/update [2] - https://stackoverflow.com/a/8307991 https://stackoverflow.com/a/8307991 [3] - https://docs.oracle.com/javaee/6/tutorial/doc/bnbqw.html#bnbrf https://docs.oracle.com/javaee/6/tutorial/doc/bnbqw.html#bnb... EDIT: Oops I accidentally replied to this twice
  - watwut 6y ago
    That is because "session.load(Person.class, 2)" line literally says "and track changes" - as article says. That is not how Hibernate or JPA is used normally. It is going out of standard way to achieve the thing you complain about.
    - eeperson 6y ago
      > That is because "session.load(Person.class, 2)" line literally says "and track changes" - as article says. I'm aware that that what occurs. That is my point. I'm responding to the previous posts statement "No calling a setter on an Entity doesn't automatically issue an sql UPDATE query". This is an example where calling a setter causes an update query to be run. > That is not how Hibernate or JPA is used normally. It is going out of standard way to achieve the thing you complain about. What about this not not how Hibernate and JPA are used normally? Are you saying that setters are not normally used? Do you mean that people normally call update or merge to persist an Entity? If so, I agree that is what people normally do. However, when people do that they tend to accidentally introduce bugs. Usually this occurs when they update an entity and then do some validation on it. When the validation fails they think they can avoid sending he changes to the DB by doing nothing. However, that isn't true. They have to manually evict the entity from the session to prevent that from happening.
- deleted 6y ago
  [deleted]
- alserio 6y ago
  If you have a managed instance of an entity, like something returned by a find or a query, calling a setter will modify its state and the state change _will_ be detected and persisted automatically on the next flush, without explicit persist or merge.