Auditability preserves a chronological record of data changes for historical review and accountability. An audit trail can record the affected entity, event type, user, and timestamp, either in a dedicated table or in versioned historical tables. section 13.2.2 section 13.3
Hibernate applications can implement auditability through two main strategies:
- A custom interceptor marks auditable entities, collects inserts and updates, and persists AuditLogRecord instances after flushing. section 13.2.2
- Hibernate Envers listens to Hibernate events, stores entity copies in audit tables, and groups modifications in transactions under revision numbers. section 13.3 section 13.3.1
- Database triggers provide another option, while application-level auditing can better preserve portability across database systems. section 13.2.2
Versioned Item history
Enable @Audited on Item and User, optionally exclude bids with @NotAudited, then create an item, modify its name and seller, and delete it in separate transactions. Envers records revisions in ITEM_AUD, USERS_AUD, and REVINFO, retaining earlier versions after deletion. section 13.3.1 section 13.3.2
