Distrust self-dirtyness status of enhanced entities which have not been created by Hibernate

Description

When other tools, such as serialization helpers, deserialize a detached enhanced entity, or otherwise materialise a new instance of the entity by calling the constructor and then setting field l(property) values via reflection, they might fail to set the dirty status correctly for fields which have been set at a value which matches the default value of the Java language.

Apparently this is a smart optimisation that some such tools perform (like Apache Jackson), and leads to bypassing the dirty status stracking implemented by SelfDirtinessTracker.

To make this foolproof, an idea which was discussed at last team meeting was to also store a state of "trusted" in the entity: this state would not be set by merely invoking the constructor (it would not be the default), but Hibernate ORM could set a managed entity to "trusted" when it's materializing the instance itself.

On merge (and similar) operations, a detached entity which is being reattached would be checked for this flag; when not set, the dirty-ness processing of the entity would fall back to use the safer, not optimised strategy.

As a side effect, it seems there's the possibility to apply some optimisations in the state handling of the SelfDirtinessTracker to reduce unnecessary allocations of tracking arrays.

Environment

None

Assignee

Sanne Grinovero

Reporter

Sanne Grinovero

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Priority

Major
Configure