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

[Emmanuel Bernard]

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.
>
> 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?
>