-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
Description:
We are using HAPI FHIR JPA Server and generating AuditEvent resources that populate AuditEvent.entity.what with references to domain resources (often versioned, e.g. ResourceType/id).
Our goal is to allow hard delete of the referenced resources while still persisting the corresponding AuditEvent.
Starting from a recent HAPI FHIR JPA version (where setEnforceReferentialIntegrityOnDeleteDisableForPaths() is available), we configured via Java the server as follows:
- enforceReferentialIntegrityOnDelete = true
- enforceReferentialIntegrityOnDeleteDisableForPaths includes:
AuditEvent.entity.what
Despite this configuration, attempting to delete a resource referenced from
AuditEvent.entity.what still fails with an error such as:
Unable to delete DocumentReference/{id} because at least one resource has a reference to this resource. First reference found as resource AuditEvent/{id} in path AuditEvent.entity.what
Observations:
- The path is correctly present in JpaStorageSettings at runtime.
- Referential integrity on delete appears to be always enforced for AuditEvent.entity.what, regardless of the disabled paths configuration.
Expected behavior:
- When AuditEvent.entity.what is listed in enforceReferentialIntegrityOnDeleteDisableForPaths, references in that path should not block deletion of the target resource.
Questions:
- Is this behavior intentional for AuditEvent?
- Is AuditEvent.entity.what explicitly excluded from RI bypass logic?
- If so, is there a recommended way to persist AuditEvent with "what" populated while still allowing hard deletes of domain resources?