jwedding ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=60a7b6e... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiODliY2FjODdl... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-15611?atlOrigin=eyJpIjoiODliY2... ) HHH-15611 ( https://hibernate.atlassian.net/browse/HHH-15611?atlOrigin=eyJpIjoiODliY2... ) CustomEntityDirtinessStrategy is always calling findDirty independent whether canDirtyCheck would return true ( https://hibernate.atlassian.net/browse/HHH-15611?atlOrigin=eyJpIjoiODliY2... ) Change By: jwedding ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=60a7b6e... ) Hi, I noticed a kind of inconvenient/inconsistent behaviour when using {{CustomEntityDirtinessStrategy}}: For checking whether an entity in general is dirty, a call to {{canDirtyCheck}} is made (which is fine): 5.6 / 6.1: [https://github.com/hibernate/hibernate-orm/blob/5.6/hibernate-core/src/ma...] // [https://github.com/hibernate/hibernate-orm/blob/6.1/hibernate-core/src/ma...] But then when searching for dirty attributes, the same check is not made anymore to the {{CustomEntityDirtinessStrategy}} therefore calling {{findDirty}}, even if the strategy is not capable of defining if the entity (and in my opinion implicitly its attributes) are dirty 5.6 // 6.1: [https://github.com/hibernate/hibernate-orm/blob/5.6/hibernate-core/src/ma...] // [https://github.com/hibernate/hibernate-orm/blob/6.1/hibernate-core/src/ma...] This is not documented (at least I didn’t find any hint mentioning this behaviour) and actually not expected in my opinion… ( https://hibernate.atlassian.net/browse/HHH-15611#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15611#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100209- sha1:597f6a7 )