Don’t want to read? You can watch it here!

Solution:

Generating SQL statements takes time and Hibernate, therefore, uses one cached SQL UPDATE statement per entity. It sets all database columns so that it can be used for all update operations. You can change that with the @DynamicUpdate annotation. It tells Hibernate to generate a new SQL statement for each update operation.

You can see an example of it in the following code snippet. The only thing you need to do is to add the @DynamicUpdate annotation to your entity class.

When you now modify the price of the Book entity, Hibernate generates an SQL statement for this operation. As you can see in the log messages, it only changes the price and version column in the Book table.

Get this Hibernate Tip as a printable PDF!

Join the free Thoughts on Java Library to get access to lots of member-only content, like a printable PDF for this post, lots of cheat sheets and 2 ebooks about Hibernate.

Learn More

You can also implement your own update statement with JPQL or the Criteria API. That allows you to customize the statement in any way you want. But please be aware, that Hibernate isn’t aware of the changes and doesn’t update its caches.

Improve Your Hibernate Skills At An In-Person Workshop

Implement Your Persistence Layer with Ease

Learn More About Hibernate

Need Some Help with Your Project?

Reader Interactions

Comments

Another great tip! Thank you Thorben. I have a question if you don’t mind: why dont’t @DynamicUpdate cache the generated query based on changed fields? In your example, if I changed the price field, Hibernate will generate an update query for this change, now if I changed the price of another entity Hibernate should just reuse the previously generated cached query instead of generating a new one. Only when I change the price AND name then Hibernate should generate a new update statement and also it should add it to its query cache so it may be used for another price and name change.

That’s a good question. I can only speculate about why they don’t cache the statement. I would expect that most applications execute so many different statements that the management overhead of the cache would be higher than the performance gain.

and then saveWithoutSelect will update the entity without first selecting it. This is easily doable and Hibernate can deduce which fields have been changed through bytecode instrumentation, but sadly there is no such API and we are forced to write a custom JPQL or HQL for such scenarios

I don’t think I get the question. Hibernate shouldn’t perform an additional query before updating an entity.
You first need to fetch the entity from the database so that it becomes managed. On this managed entity, you can then call your setter methods to change entity attributes. That makes the entity dirty, and Hibernate executes the update during the next flush operation. You don’t need to call any method on your Session for that and Hibernate doesn’t perform any additional query.

You don’t need to know which entity attributes you are going to update. Hibernate identifies the changed attributes during the dirty check.
Without the @DynamicUpdate, Hibernate executes an SQL UPDATE statement that changes all database columns, if the value of at least one entity attribute changed.
With the @DynamicUpdate, Hibernate identifies which attributes were changed and generates an SQL UPDATE statement that only includes these attributes/columns.