glassfish
  1. glassfish
  2. GLASSFISH-1167

No dependency mgnt while deleting self-relationship

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 9.1pe
    • Fix Version/s: 9.1pe
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,167

      Description

      The class Employee has a self relationship <manager>. The relationship
      is mapped as follows:

      @Entity
      public class Employee {

      @Id private long id;
      @ManyToOne @JoinColumm(name=MANAGER_ID)
      private Employee manager;

      ...
      }

      The following code leads to a Foreign Constraint violation on the database:

      tx.begin();
      e = new Employee(1L);
      e2 = new Employee(2L);
      em.persist(e);
      em.persist(e2);
      e2.setManager(e);
      tx.commit();

      tx.begin();
      em.remove(e2);
      em.remove(e);
      tx.commit();

      The order of DELETE statements issued to the database is not
      calculated based on foreign key dependencies. This leads to a foreign
      key violation, if Employee e is deleted before e2. Missing dependency
      management manifests itself only on deletes, not for inserts/updates.

        Activity

        Hide
        mareks added a comment -

        cc

        Show
        mareks added a comment - cc
        Hide
        mf125085 added a comment -

        Raising to 1597's priority.

        Show
        mf125085 added a comment - Raising to 1597's priority.
        Hide
        gyorke added a comment -

        This is not the same issue as 1597. This is resolved through spec required user
        relationship maintenance. It is the user's responsibility to remove the
        reference to e before it is removed. e in this case could be referenced by any
        Employee not necessarily e2. Having generic relationship tracking and
        maintenance added to handle this case slows down a system and adds unnecessary
        overhead when the situation can be resolved with a simple relationship update by
        the user. Automatic relationship maintenance was removed from the specification
        for very good reasons.
        Any solution to this issue would have to add only a negligible amount of overhead.

        Show
        gyorke added a comment - This is not the same issue as 1597. This is resolved through spec required user relationship maintenance. It is the user's responsibility to remove the reference to e before it is removed. e in this case could be referenced by any Employee not necessarily e2. Having generic relationship tracking and maintenance added to handle this case slows down a system and adds unnecessary overhead when the situation can be resolved with a simple relationship update by the user. Automatic relationship maintenance was removed from the specification for very good reasons. Any solution to this issue would have to add only a negligible amount of overhead.
        Hide
        mf125085 added a comment -

        Created an attachment (id=907)
        Testcase changed to set relationship on both sides

        Show
        mf125085 added a comment - Created an attachment (id=907) Testcase changed to set relationship on both sides
        Hide
        mf125085 added a comment -

        Gordon is correct: The user must remove the relationships explicitly. But the
        fix for issue 1597 solves this situation for the updated test case as the
        objects are removed in the correct order now.

        Show
        mf125085 added a comment - Gordon is correct: The user must remove the relationships explicitly. But the fix for issue 1597 solves this situation for the updated test case as the objects are removed in the correct order now.

          People

          • Assignee:
            mf125085
            Reporter:
            mf125085
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: