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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
