If an entity has an audited BigDecimal property and an unaudited property that is changed in an update, an audit record is created, even if the BigDecimal value has not changed.
This is due to the areEqual implementation in org.hibernate.internal.util.compare.EqualsHelper which simply calls the equals method instead of using "compareTo == 0" like the areEqual method in the org.hibernate.type.descriptor.java.BigDecimalTypeDescriptor
Windows, Wildfly 10.1.0.Final
, I haven't been able reproduce this with a simple entity as follows:
I've tested several scenarios
Update entity text property, yields no audit row.
Update entity text and value propery where value is set to a new instance of BigDecimal with the same double value, yields no audit row.
Update entity value property with a new instance of BigDecimal with different double value, yields audit row.
It seems regardless of scenario, the expected behavior is observed. Perhaps you could attach a test case that highlights the problem more clearly?
I attached a small test case that reproduces the error. The build war can be put in a wildfly server with the default example DS and the test will run automatically when the war is deployed.
Thanks for the test case, that highlighted the problem nicely.
I do agree blindly delegating to EqualsHelper is incorrect. The SinglePropertyMapper should hold a reference to a type or descriptor for which it delegates comparisons to, allowing not only this BigDecimal use case to work as intended; however, to support custom type implementation equality checks appropriately.
In order to avoid any performance issues, we'll attempt to cache the Type up-front during construction of these mappers and delegate there for comparison needs to avoid this issue with BigDecimal & potentially other types.