[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3958) Superfluous generated updates cause Violation of UNIQUE KEY constraint

[Guenther Demetz (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-3958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46591#comment-46591 ] 

Guenther Demetz commented on HHH-3958:
--------------------------------------

Issue to reject or close.
After further investigation, I saw that mentioned updates are not superfluous at all:
without them, the testcase runs into 
ConstraintViolationException: The DELETE statement conflicted with the REFERENCE constraint "FK4273D5145F". The conflict occurred in table "B", column 'assA_oid'.
because it deletes A instances, while they are still referenced by B instances ( deletions are executed in the exact order as they were invoked ).

Conclusion: it's up to the user to perform the deletions in the correct sequence, in this use-case it is:

em.remove(b1); // first the FK-owner object
em.remove(a1); // then  the object referenced by FK 

em.remove(b2); // as above
em.remove(a2);

> Superfluous generated updates cause Violation of UNIQUE KEY constraint
> ----------------------------------------------------------------------
>
>                 Key: HHH-3958
>                 URL: https://hibernate.onjira.com/browse/HHH-3958
>             Project: Hibernate ORM
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.3.1
>         Environment: 3.3.1 GA, SQLServer 2008
>            Reporter: Guenther Demetz
>            Priority: Minor
>         Attachments: Testcase.jar
>
>
> When deleting a entire closure of objects associated over @ManyToOne within one single transaction, then on commit
> the FlushEventListener creates update statements on objects which are going to be deleted anyway.
> These update statements seems not only be useless, 
> in certain scenarios they lead to Constraint Violation Exceptions, see the example here:
> @Entity
> public class A {
>     public A() { }
>     @Id @GeneratedValue
>     private long oid;
> }
> @Entity
> @Table(uniqueConstraints = {@UniqueConstraint(columnNames={"assA_oid"})})
> public class B {
>     public B() {};
>     
>     @Id @GeneratedValue
>     private long oid;
>    
>     @javax.persistence.ManyToOne
>     protected A assA = null;
> }
> A a1 = new A();         em.persist(a1);
> A a2 = new A();         em.persist(a2);
>         
> B b1 = new B();
> b1.assA = a1; // set unique association
> B b2 = new B();
> b2.assA = a2; // set unique association
> em.persist(b1);
> em.persist(b2);        
> em.getTransaction().commit();     
> em.getTransaction().begin();
>         
> em.remove(a1);
> em.remove(a2);
> em.remove(b1);
> em.remove(b2);
>         
> em.getTransaction().commit();  
> // p6spy report:
> // update B set assA_oid='',version=0 where oid=1 and version=0 
> // update B set assA_oid='',version=0 where oid=2 and version=0 --> this raises "Violation of UNIQUE KEY constraint on all DB's which don't allow multiple null values in a unique index
> See testcase in attachment

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira