[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Erik-Berndt Scheper commented on HHH-5559: ------------------------------------------ Hi, I have been bitten by this as well. But I am wondering if changing this will not violate the JPA 2 specification. Paragraph 11.1.37 OneToOne Annotation (page 402) says: {quote} If orphanRemoval is true and an entity that is the target of the relationship is *removed* from the relationship *(by setting the relationship to null)*, the remove operation will be applied to the entity being orphaned. If the entity being orphaned is a detached, new, or removed entity, the semantics of orphanRemoval do not apply. If orphanRemoval is true and the remove operation is applied to the source entity, the remove operation will be cascaded to the relationship target in accordance with the rules of section 3.2.3, (and hence it is not necessary to specify cascade=REMOVE for the relationship). The remove operation is applied at the time of the flush operation. The orphanRemoval functionality is intended for entities that are privately "owned" by their parent entity. Portable applications must otherwise not depend upon a specific order of removal, and must not reassign an entity that has been orphaned to another relationship or otherwise attempt to persist it. {quote} However in the issue at hand, the entity is not removed by setting the relation to null, but by changing the value of the relation. WDYT? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Erik-Berndt Scheper commented on HHH-5559: ------------------------------------------ Hi, I've created a testcase to reproduce this problem. This leaves open the question if this is a JPA 2.0 spec corner case. Hopefully someone of the Hibernate team can answer this. Regards, Erik-Berndt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Erik-Berndt Scheper commented on HHH-5559: ------------------------------------------ B.T.W. The attached patch verifies: * That setting the reference to null correctly removes the orphaned entity (testcase succeeds) * That setting the reference to another entity does not remove the orphaned entity (testcase fails) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Erik-Berndt Scheper commented on HHH-5559: ------------------------------------------ B.T.W. The attached patch verifies: * That setting the reference to null correctly removes the orphaned entity (testcase succeeds) * That setting the reference to another entity does not remove the orphaned entity (testcase fails) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Emmanuel Bernard commented on HHH-5559: --------------------------------------- Hi guys, let me paraphrase the issue at hands. You have an object a pointing to b1 (with the orphanRemoval set on the association). When a and b are detached, then you replace the association (a.setB(b2);) and expect b1 to be removed. We cannot implement that (not efficiently at least) and the spec provision against that "If the entity being orphaned is a detached, new, or removed entity, the semantics of orphanRemoval do not apply." The reason it's hard is that, we need to query the DB and load b1 to remove it. When designing the spec, we've decided against forcing such behavior. So when using orphanRemoval, make sure to work on attached objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Erik-Berndt Scheper commented on HHH-5559: ------------------------------------------ Hi, Yes, you paraphrased the testcase correctly. And of course, for detached entities it's entirely reasonable that orphanRemoval does not apply. This was a stupid error in the attached testcase, method: testOneToOneOrphanRemovalUpdateReference(). I should have reloaded the entity in the session, just like the other method: testOneToOneOrphanRemovalSetNull() I.e. between line 55 and 56 there should have been: + owner = (Owner) session.load(Owner.class, idOwner); I've created a new patch file where the entity is not detached. And still orphanRemoval does not apply, i.e. the testcase fails. However, I've already come to the conclusion that this orphan removal for updating a one-to-one relation doesn't make any sense. I.e. from a database point of view, this leads to: -Insert and delete a row in the child table (and index updates) -Update a reference to the child table in the owner table (unless the reference to the owner is held in the child table). Instead of creating a new entity, I now update the fields in the original entity, which leads to a single row update of the child table, which is much more efficient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Koen Molkenboer commented on HHH-5559: -------------------------------------- I would like to re-open this issue, because of the following reasons: 1. It is part of the JPA 2.0 specification 2. We are doing Domain Driven Design, where it is not possible to change the values of a 'Value Object' and we need to create a new 'Value Object' whenever values need to be modified, thereby implicitly making the previous value object an orphan. Thanks in advance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] justin mares commented on HHH-5559: ----------------------------------- I would like to vote for this but this is no longer possible. Today I manually delete orphaned entity but I would like to have Hibernate transparently handling it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-5559?page=c... ] Matt Kirk commented on HHH-5559: -------------------------------- I've been hit by this today and will vote on it being fixed. For those interested the work around we implemented was to change the mapping to OneToMany and manage the collection inside the entity such that clients only get a OneToOne view of the child record as follows: @Entity public class Child { ... } @Entity public class Parent { @OneToMany(..., orphanRemoval = true) private Set<Child> children = new HashSet<Child>(); .... public Child getChild() { if (children.size() == 1) { return children.iterator().next(); } return null; } public void doSomethingThatCreatesNewChild() { if (getChild() != null) { children.remove(getChild()); } children.add(new Child()); } } This approach suits us better than having to make child entity table columns in the DB nullable and updating the same record each time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira