Bad proxy behavior when using store_data_at_delete and audited parent/child relationships
hltbdivl Mar 5, 2013 1:55 PMUse 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.