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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
