Uploaded image for project: 'Hibernate ORM'
  1. HHH-8057

Bad proxy behavior when using store_data_at_delete and audited parent/child relationships

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: hibernate-envers
    • Labels:
      None
    • Bug Testcase Reminder (view):

      Bug reports should generally be accompanied by a test case!

    • Last commented by a user?:
      true
    • Sprint:

      Description

      Use hibernate.envers.store_data_at_delete = true

      class Parent {
        @Audited
        String name;
      
        Set<Child> children;
      }
      
      class Child {
        @Audited
        String name;
      
        @Audited
        Parent parent;
      
        public int hashCode() {
          return Objects.hashCode(name, parent);
        }
      }
      

      Transaction 1:
      Creates a parent.
      Creates a child for it.

      You get one revision, one Parent_AUD (create), and one Child_AUD (create).

      Transaction 2:
      Deletes the parent.
      Deletes the child. In my case, this is via cascade.

      You get one revision, one Parent_AUD (delete), and one Child_AUD (delete).

      Transaction 3:
      Lookup using the following code:

      AuditReaderFactory.get(em)
      .createQuery()
      .forRevisionsOfEntity(Child.class, true, true)
      .getResultList();
      

      This throws an exception:

      javax.persistence.EntityNotFoundException: Unable to find com.cloudera.cmf.model.DbService with id 1
                at org.hibernate.ejb.Ejb3Configuration$Ejb3EntityNotFoundDelegate.handleEntityNotFound(Ejb3Configuration.java:155)
                at org.hibernate.proxy.AbstractLazyInitializer.checkTargetState(AbstractLazyInitializer.java:171)
                at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:160)
                at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:195)
                at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:185)
                at Parent_$$_javassist_2.hashCode(Parent_$$_javassist_2.java)
                at java.util.Arrays.hashCode(Arrays.java:3655)
                at com.google.common.base.Objects.hashCode(Objects.java:77)
                at Child.hashCode(Child.java:385)
                at org.hibernate.envers.tools.Triple.hashCode(Triple.java:74)
                at java.util.HashMap.put(HashMap.java:372)
                at org.hibernate.envers.reader.FirstLevelCache.putOnEntityNameCache(FirstLevelCache.java:87)
                at org.hibernate.envers.entities.EntityInstantiator.createInstanceFromVersionsEntity(EntityInstantiator.java:104)
                at org.hibernate.envers.query.impl.RevisionsOfEntityQuery.list(RevisionsOfEntityQuery.java:134)
                at org.hibernate.envers.query.impl.AbstractAuditQuery.getResultList(AbstractAuditQuery.java:105)
                ...
      

      When store_data_at_delete is true, the second Child_AUD entry contains a link to Parent_AUD, instead of a NULL. The audit query tries to build Child entities out of the two Child_AUD entries but fails for the second one. Why does it fail? Because the SQL query it uses to fetch the correct Parent_AUD entry ignores entries with revision type DEL. Here's the corresponding comment from EntitiesAtRevisionQuery.list():

              /*
               * The query that we need to create:
               *   SELECT new list(e) FROM versionsReferencedEntity e
               *   WHERE
               * (all specified conditions, transformed, on the "e" entity) AND
               * (selecting e entities at revision :revision)
               *   --> for DefaultAuditStrategy:
               *     e.revision = (SELECT max(e2.revision) FROM versionsReferencedEntity e2
               *       WHERE e2.revision <= :revision AND e2.id = e.id) 
               *     
               *   --> for ValidityAuditStrategy:
               *     e.revision <= :revision and (e.endRevision > :revision or e.endRevision is null)
               *     
               *     AND
               * (only non-deleted entities)
               *     e.revision_type != DEL
               */
      

      I think the right thing to do here is relax that last condition when we're fetching a relation for a DEL audit entry.

      Here's the corresponding forum post: https://community.jboss.org/message/800890

        Attachments

          Issue links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: