[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