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
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(),
> (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