EntityManager.merge functionality difference between hibernate 4.1.9 and hibernate 5.2.11

Hibernate ORM
1

EntityManager.merge() functionality difference between hibernate 4.1.9 and hibernate 5.2.11.

As the queries are getting fired even though there is changes in the object after .merge()

which was not in hibernate 4.1.9 version.

Can you guys please help

2

What queries are you talking about. Add a code example and the SQL queries that get executed.

3

insert and update queries like

insert into child_table()
insert into child_table()
insert into child_table()
then update query

update parent_table()

4

It’s still not clear what you are talking about. Real code and real logs are needed instead.

5

So below is the example.

In v4.1.9

public void daoPersist(obj)
{
      entityManager.merge(obj);
      obj.setA(a);
      //some logic
      obj.setB(b);

      //The queries to db get executed at this point ie. at the end of the function
}

whereas in v5.2.11

public void daoPersist(obj)
{
      entityManager.merge(obj);

      //The queries to db get executed at this point ie. at this point of the function

      obj.setA(a);
      //some logic
      obj.setB(b);
}

Hence as you can see in the above code that in v5.2.11 the since the db calls are happening before setters are getting called the correct data isn’t getting persisted in the db.

We are not able to figure out why in the 2 versions of hibernate the internal calls to db are happening at 2 different places in the function.

Kindly help. :slight_smile:

6

This line of code is wrong:

It should be:

obj = entityManager.merge(obj);

For more details, check out this article.

More, why do you call merge in a method which is called daoPersist? Merge is for reattaching entities. It’s not a global save method. Use persist for new entities.

7

The daoPersist function is just a name. We make sure that out daoPersist function gets called only when the obj.getId() != null (this is in an outer function though) ie. and the id is not null only when this obj exists in the db.
We are checking our hibernate debug logs and we observed that only the update queries were fired against the merge() statement whereas it should have been actually firing the select queries and then the update queries.

8

Merge always issues a select if the entity is not already managed. An update is executed only if the entity gets modified. That’s how it’s designed to work.

9

Our issue is that the same piece of code works for v4.1.9 but doesn’t work for v5.2.11

As explained in the functions above, in v5.2.11 the insert queries get fired to the db right when the entityManager.merge(obj) statement gets executed it doesn’t wait for setters to execute at all

whereas in v4.1.9 the select/insert queries get fired to the db right at the end ie. after the setters get executed (looks like when transaction ends) and not when the entityManager.merge(obj) statement gets executed.

10

Try to replicate it with this test case template:

http://in.relation.to/2016/01/14/hibernate-jpa-test-case-template/