2 Replies Latest reply on Mar 8, 2013 2:20 AM by hltbdivl

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

    hltbdivl

      Use hibernate.envers.store_data_at_delete = true

       

      {code}

      class Parent {

        @Audited

        String name;

       

        Set<Child> children;

      }

       

      class Child {

        @Audited

        String name;

       

        @Audited

        Parent parent;

       

        public int hashCode() {

          return Objects.hashCode(name, parent);

        }

      }

      {code}

       

       

      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:

      {code} 

      AuditReaderFactory.get(em)

      .createQuery()

      .forRevisionsOfEntity(Child.class, true, true)

      .getResultList();

      {code}


      This throws an exception:

      {quote}

      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)

                ...

      {quote}

       

      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:

      {code}

              /*

               * 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

               */

      {code}

       

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