This is consistent with the way saveOrUpdate works

Emmanuel, do you mean saveOrUpdateCopy? Since saveOrUpdate doesn't do any copying of the values onto another instance. By the way, the "dirtying" of the non-updatable field I described also holds for collections. This means that DefaultMergeEventListener does a source.load(), gets a fully valid object with proxied collections (which would later be lazy-loadable with the current values), copies _invalid_ values on top of the clean proxied collection, and sends that back to the user. Seems counter-productive. Thanks, Josh. Emmanuel Bernard wrote: > This is consistent with the way saveOrUpdate works > > Josh Moore wrote: >> >> Using Hibernate with non-updatable fields can leave entities in a >> confused state. >> >> Take an Image with a field creationEvent, not updatable. If >> Image.creationEvent is set on an instance and passed to >> session.merge(), >> then: >> >> (1) Properly, no UPDATE is issued. >> (2) DefaultMergeEventListener.copyValues copies the invalid >> creationEvent to the new instance >> (3) The client who receives that instance thinks creationEvent has been >> successfully updated. >> >> What are the semantics here? Should the spec specify this? Max, you >> mentioned via irc that this wasn't in the spec, but I assume >> >> @Column( updatable = false ) >> >> >> would cause the same issue. >> >> Currently I'm writing logic in my MergeEventListener to NOT copy these >> values (difficult because of the EmbeddedComponentTypes I'm using). It >> seems, however, that this should be belong directly to >> DefaultMergeEventListener. >> >> Opinions?

No I mean saveOrUpdate Think about how saveOrUpdate works in your case, and you will see that merge is very consistent. Josh Moore wrote: > Emmanuel, do you mean saveOrUpdateCopy? Since saveOrUpdate doesn't do > any copying of the values onto another instance. > > By the way, the "dirtying" of the non-updatable field I described also > holds for collections. This means that DefaultMergeEventListener does > a source.load(), gets a fully valid object with proxied collections > (which would later be lazy-loadable with the current values), copies > _invalid_ values on top of the clean proxied collection, and sends > that back to the user. > > Seems counter-productive. > > Thanks, > Josh.