[watwut]

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]

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

[watwut]

The "session.load(Person.class, 2)" thing is not done normally. It is not even part of JPA. It is hibernate only feature.

So in all project I have seen, calling setter did not changed database.

> Do you mean that people normally call update or merge to persist an Entity?

Yes, people normally call update and merge to persist an entity.

[alserio]

People normally do that when they do not have to do that.

  Dog rex = em.find(Dog.class,"rex"); // 1
  rex.setAge(2); // 2
  // other query // 3

At 3 the update is flushed on the underlying db. This is pure JPA. Calling merge is forcing an useless query before the update. Also, merge returns the managed entity.