Hibernate Dirty-Checking with Converted Attributes

  1. Load entities A, B, C of type Dummy.
  2. Some logic determines that those entities should get deleted.
  3. Ran a Hibernate CriteriaDelete query which basically did “DELETE FROM DUMMY WHERE ID IN (A, B, C);”
  4. The transaction gets committed and suddenly Hibernate tried to run updates on the entities. This obviously failed since the entities no longer existed in the DB.

Typical reason & how to investigate

The updates that Hibernate tried to run would have been obvious to me if we had modified the entities A, B or C after loading them, however that was not the case — at least not in any obvious way.

Snippet from DefaultFlushEntityEventListener.java
@Column(columnDefinition = "VARCHAR")
@Convert(converter = TestDtoConverter.class)
public TestDto getTestDto() {

The anticlimactic truth

This makes sense and is also correct, in the end it turned out that the problem was caused by some code somewhere had reassigned the attribute to a new object. An exact, identical copy, but a new object nonetheless.

Takeaways

I still think this is interesting and something to keep in mind, think about this:

--

--

Software engineer from Austria. Passionate about software, likes photography, addicted to podcasts and always busy. http://paukl.at

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Paul Klingelhuber

Paul Klingelhuber

80 Followers

Software engineer from Austria. Passionate about software, likes photography, addicted to podcasts and always busy. http://paukl.at