|
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:
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
|
Major