We're updating the issue view to help you get more done. 

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

Description

Use hibernate.envers.store_data_at_delete = true

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 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:

1 2 3 4 AuditReaderFactory.get(em) .createQuery() .forRevisionsOfEntity(Child.class, true, true) .getResultList();

This throws an exception:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 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():

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 /* * 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

Environment

None

Status

Assignee

Lukasz Antoniak

Reporter

Adar Dembo

Components

Priority

Major