We have
which is extended by an AbstractPerson type;
which is extended by a Customer type
when a field in the Customer type is updated (via a setter), there is no update of the "modifiedAt" time, and it will remain at the createdAt time. The only issued SQL statement for the update is;
Actually, removing the refresh() doesn't help. If I just call the setEmail method and then commit, I get the same result at SQL level, although the modifedAt field in the entity will be correct after the commit.
IMHO, it is inconsistent at best.
So, in this testcase, the entity is created and committed, then loaded, changed and committed, and finally loaded and checked.
UnitOfWork.complete() in terms of EntityManager, only calls EntityManager.commit()
The Queries uses JPA TypedQuery.
Here is a complete testcase, showing the problem as I see it.
Hi ,
it seems that when a property not belonging to the Parent class is modified the createdAt property is not updated.
the updateParentClassProperty works but the updateSubClassProperty fails.
Yes, that is a reasonable conclusion, but since the field itself is updated, it is that the "update" manages to bypass the detection of change, and it is difficult for me to figure out where inside Hibernate start digging for that, and hope to have experts look into it.
FTR, I have circumvented this bug by adding the update in onFlushDirty() interceptor which works.
Hi ,
thanks for the feedback, I'll look into it.