[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-2864) Merging a detached instance with a new child in a unidirectional one-to-many association fails if the parent was previously loaded as a proxy

Merging a detached instance with a new child in a unidirectional one-to-many association fails if the parent was previously loaded as a proxy --------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2864 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2864 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.1.3, 3.2.5 Environment: Tested with Hibernate 3.1.3 and 3.2.5 on HSQL and Oracle 9, using JDK 1.4 and 1.6. The behavior is the same in each case. Reporter: Carl-Eric Menzel Assignee: Steve Ebersole Fix For: 3.2.6, 3.3 Attachments: DefaultMergeEventListener.java-patch, ProxyMergeTest.zip Given a class One and a class Many with a unidirectional one-to-many relationship. I'm getting a PropertyValueException: "not-null property references a null or transient value: test.Many._toManyBackref" when merging a detached "One" instance which contains a new "Many" instance if and only if the "One" was previously loaded as a proxy in the same transaction. The meat of the problem: // create new One One one = new One(); one.setOneOther(new One()); session.save(one); commitAndGetNewSession(); /* * load saved instance as a proxy, but do not use it. we could use get() so we wouldn't get a proxy, but a real-world * application might have only loaded this instance transitively as a proxy before merging a detached instance, so this is a * real problem. */ Object proxyWeDontUse = session.load(One.class, new Integer(one.getId())); assertTrue(proxyWeDontUse instanceof HibernateProxy); // use detached instance and add a Many one.getToMany().add(new Many()); // merge the detached instance. this should work, but doesn't. the backref-getter doesn't correctly // find the parent object of the new Many, because the copyCache/mergeMap only contains the proxy loaded // above, but the entityEntries in PersistenceContext contain the raw unproxied object. session.merge(one); In this simplified testcase I explicitly load the proxy. In our actual scenario, the One is loaded transitively as a child of yet another parent object - usually as a proxy. We need to load this to perform some authorization checks before we can actually merge the incoming detached One instance. This leads to the situation of having the proxy first and only then merging. As far as I understand the documentation, this *should* work. I spent quite some time getting to the bottom of this - mostly debugging through the MergeEventListener. I found this: DefaultMergeEventListener uses Session.get() to load the persistent instance when merging a detached one. get() returns the proxy that was previously created. DefaultMergeEventListener then stores this returned proxy as the value of an entry in the copyCache. Later the backref-getter gets the actual persistent instance from the PersistenceContext and uses this to look for the detached instance in the mergeMap (which is the inverted copyCache, if I understood that correctly). But this only returns null, since the only key it can see is the *proxy* that was put as a value into the copyCache. Thus the backref-getter can't find its backref, leading to the exception. Proposed solution: Store the persistent instance in the copyCache instead of the proxy, or do some dereferencing magic when looking for the backref. I can't judge that though - all I know about this right now comes from several hours of serious debugging. I'm attaching an almost ready-to-use testcase as a zipped Eclipse project. Sources and config are in src/, the lib/ directory contains a hsqldb.jar which I used for fast testing. Simply add the required Hibernate jars and run the MergeUnidirectionalOneToManyTest. We currently use Hibernate 3.1.3 in production, but the problem occurs with 3.2.5 as well. A patched 3.1 release would be the best for us, but I'm not sure whether that is possible. Thanks! Carl-Eric Menzel Senacor Technologies AG