Re: [hibernate-dev] More fun with merging : non-updatable fields

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?