|
|
|
|
Re: Problems with @PreUpdate and flush() [message #499690 is a reply to message #498894] |
Mon, 23 November 2009 18:05 |
|
In order to raise the preUpdate events, the object's changes must be computed, if you then change the object again in this event, then new changes will not be picked up (as this would require us re-computing the changes again, which would be twice as much work, but might be a useful option to have).
You can use the DescriptorEvent preUpdate instead of the JPA event, this will give you access to the DescriptorEvent object, which has an API, updateAttributeWithObject(), which will update the object, row and change set.
James : Wiki : Book : Blog : Twitter
|
|
|
|
Re: Problems with @PreUpdate and flush() [message #663762 is a reply to message #499756] |
Wed, 06 April 2011 12:47 |
|
Thomas wrote on Tue, 24 November 2009 07:32 | James,
thanks for that. I was trying to avoid any provider specific API and isn't JPA's preUpdate event intended to give an EntityListener the chance to modify the updated objects? Mind you, that it all works fine if you don't do a flush() and end the transaction normally. So I think it's a bug with EclipseLink's flush.
Cheers
Thomas
|
Is still happening with the latest EclipseLink ?
Will the following code work as intended ?
@PreUpdate
@PrePersist
public void updateTimeStamps() {
lastModified = new Date();
if (dateCreated==null) {
dateCreated = new Date();
}
}
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04058 seconds