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

[Josh Moore]

Sorry, Christian, didn't get your emails because of a delayed digest 
message. And I agree that it can be seen as reasonable behavior. With 
saveOrUpdate (as Emmanuel was pointing out) one gets

  * in DB: no change
  * in memory: (invalid) change

and with these semantics for merge:

  * in DB: no change
  * in memory: (invalid) change.

Understood. I think there's a case to be made, however, for not 
expending extra time for merge to make the in memory representation 
invalid. For me it's a part of what "merge" means : "Take the DB 
representation and the in-memory representation and produce something 
_new_". I.e. I'm expecting to have to deal with that situation. 
SaveOrUpdate differs in that I still have my in-memory object 
references, so no one should screw with them. Merge is polar opposite. 
I'm given new references and have to, somehow, deal with this new state. 
My opinion, which is nothing more than that, is : it'd be nice if those 
new object references were valid.

But, *shrug*, whatever. If those aren't desired or generally useful 
semantics, I'll finish implementing the logic for my MergeEventListener. 
I could use some help getting hold of EmbeddedComponentType's metamodel 
(see 
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1907). But 
I'll catch Max on irc for that. ;)

Thanks again,
  Josh.


P.S. one last thing, Christian. You mentioned "Don't [apply those 
values] if you don't want [them]", though there's one case where it's 
actually "Then do [appply those values] if you want [them]". Namely on 
the reverse side of a bidirectional many-to-one. If you call 
child.setParent(parent) and not parent.getChildren().add(child), then 
you'll get a parent back which still doesn't have children in it. A bit 
freaky the first time you experience it. And no, Hibernate doesn't do 
CMR, but it also needn't go out of it's way to NOT do CMR. Cheers.


Christian wrote:
>> This is consistent with the way saveOrUpdate works
> 
> And it's perfectly reasonable behavior. If I modify a field value,  
> then merge, then take the instance returned by merge, I expect that  
> the value is still there in the merged result. That has nothing to do  
> with the update/UPDATE behavior of Hibernate.

>> copies _invalid_ values on top of the clean proxied collection, and  
>> sends that back to the user.
> 
> It does so because you applied these values. Don't do that if you  
> don't want it. Thanks to Hibernate your mistake will not end up in  
> the database.

Max wrote:
> 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