The spec has always said that callback listeners are allowed to mutate entity state, and this includes @PreUpdate, which is now been sorta re-characterized as representing an event associated with the database UPDATE operation, not the mutation of the entity itself.
I have run into a discomfort with this that for the end user probably isn't very significant but for me as an implementor feels quite unnatural.
The issue is that I can't really call @PreUpdate right before executing the SQL UPDATE, or @PreInsert right before executing the INSERT, because I have to know the final state of the entity earlier than that, to even know if I'm going to execute the UPDATE or INSERT. So right now these things need to happen during what we in Hibernate think of as the "pre-flush" phase of flushing, and not during execution of the "actions".
This isn't terrible but it's not really what I felt these events were supposed to represent.
On way to recover the behavior I thought I was getting would be to allow a callback listener method to specify that it doesn't mutate the entity (that also allows a useful performance optimization). So, something like:
@NonMutating @PreInsert
void beforeInsert(Book book) {
...
}A @NonMutating listener could be called closer to the database operation.
I guess the question is: is this a sufficiently-general thing (and I know my description was kinda handwavey) or is it something very specific to our implementation?
The spec has always said that callback listeners are allowed to mutate entity state, and this includes
@PreUpdate, which is now been sorta re-characterized as representing an event associated with the databaseUPDATEoperation, not the mutation of the entity itself.I have run into a discomfort with this that for the end user probably isn't very significant but for me as an implementor feels quite unnatural.
The issue is that I can't really call
@PreUpdateright before executing the SQLUPDATE, or@PreInsertright before executing theINSERT, because I have to know the final state of the entity earlier than that, to even know if I'm going to execute theUPDATEorINSERT. So right now these things need to happen during what we in Hibernate think of as the "pre-flush" phase of flushing, and not during execution of the "actions".This isn't terrible but it's not really what I felt these events were supposed to represent.
On way to recover the behavior I thought I was getting would be to allow a callback listener method to specify that it doesn't mutate the entity (that also allows a useful performance optimization). So, something like:
A
@NonMutatinglistener could be called closer to the database operation.I guess the question is: is this a sufficiently-general thing (and I know my description was kinda handwavey) or is it something very specific to our implementation?