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

Josh Moore josh.moore at gmx.de
Wed Sep 27 14:48:26 EDT 2006


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?



More information about the hibernate-dev mailing list