diff --git a/documentation/src/main/docbook/devguide/en-US/Envers.xml b/documentation/src/main/docbook/devguide/en-US/Envers.xml index 293217c8d0..2e5c8b8eff 100644 --- a/documentation/src/main/docbook/devguide/en-US/Envers.xml +++ b/documentation/src/main/docbook/devguide/en-US/Envers.xml @@ -218,6 +218,41 @@ +
+ Additional mapping annotations + + + The name of the audit table can be set on a per-entity basis, using the + @AuditTable annotation. It may be tedious to add this + annotation to every audited entity, so if possible, it's better to use a prefix/suffix. + + + + If you have a mapping with secondary tables, audit tables for them will be generated in + the same way (by adding the prefix and suffix). If you wish to overwrite this behaviour, + you can use the @SecondaryAuditTable and + @SecondaryAuditTables annotations. + + + + If you'd like to override auditing behaviour of some fields/properties in an embedded component, you can use + the @AuditOverride(s) annotation on the usage site of the component. + + + + If you want to audit a relation mapped with @OneToMany+@JoinColumn, + please see for a description of the additional + @AuditJoinTable annotation that you'll probably want to use. + + + + If you want to audit a relation, where the target entity is not audited (that is the case for example with + dictionary-like entities, which don't change and don't have to be audited), just annotate it with + @Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED). Then, when reading historic + versions of your entity, the relation will always point to the "current" related entity. + +
+
Choosing an audit strategy