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

[Max Rydahl Andersen]

Yes, Josh - consider especially the situation Christian explained that if  
you merge Xy onto a session you expect the returning object is Xy and not  
Xx.

If you want this behavior (which in some cases I can see the usefullness  
of) you need to have
a custom merge implementation as you already have.

/max

>
> Thanks, Emmanuel. I'll ponder that tonight. And I'll try to convince  
> myself that being consistent with saveOrUpdate is a good thing for  
> merge, but I'm not hopeful. ;)
>
> Cheers,
>   Josh.
>
> Emmanuel Bernard wrote:
>> 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.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com