You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/src/main/asciidoc/userguide/chapters/envers/Envers.adoc
+58-12Lines changed: 58 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -270,15 +270,16 @@ Only used if the `ValidityAuditStrategy` is used, and `org.hibernate.envers.audi
270
270
When set to `true`, the legacy mapping behavior is used such that the revision end timestamp is only maintained in the root entity audit table.
271
271
When set to `false`, the revision end timestamp is maintained in both the root entity and joined subclass audit tables; allowing the potential to apply database partitioning to the joined subclass tables just like the root entity audit tables.
Should entity types, that have been modified during each revision, be tracked.
284
285
The default implementation creates `REVCHANGES` table that stores entity names of modified persistent objects.
@@ -484,18 +485,49 @@ Either a `long/Long` or `java.util.Date` value representing the instant at which
484
485
When using a `java.util.Date`, instead of a `long/Long` for the revision timestamp, take care not to store it to a column data type which will lose precision.
485
486
486
487
Envers handles this information as an entity.
487
-
By default it uses its own internal class to act as the entity, mapped to the `REVINFO` table.
488
-
You can, however, supply your own approach to collecting this information which might be useful to capture additional details such as who made a change
488
+
489
+
[[envers-default-revision-entity]]
490
+
==== Default Revision Entity
491
+
492
+
By default, Envers uses its own internal class to act as the entity, mapped to the `REVINFO` table.
493
+
The entity type that's used depends on a couple configuration properties: <<envers-config-native-id,native identifiers>> and <<envers-config-track-entities, entity tracking>>. Here is a table showing the entity type used based on the configuration values:
You can also supply your own approach to collecting this information which might be useful to capture additional details such as who made a change
489
513
or the IP address from which the request came.
490
514
There are two things you need to make this work:
491
515
492
516
. First, you will need to tell Envers about the entity you wish to use.
493
517
Your entity must use the `@org.hibernate.envers.RevisionEntity` annotation.
494
518
It must define the two attributes described above annotated with `@org.hibernate.envers.RevisionNumber` and `@org.hibernate.envers.RevisionTimestamp`, respectively.
495
-
You can extend from `org.hibernate.envers.DefaultRevisionEntity`, if you wish, to inherit all these required behaviors.
519
+
You can extend from any of the revision mapped superclass types, if you wish, to inherit all these required behaviors:
Simply add the custom revision entity as you do your normal entities and Envers will *find it*.
498
528
+
529
+
To understand which mapping you should extend based on configuration see the <<envers-default-revision-entity,default revision entity>> paragraph.
530
+
+
499
531
NOTE: It is an error for there to be multiple entities marked as `@org.hibernate.envers.RevisionEntity`.
500
532
501
533
. Second, you need to tell Envers how to create instances of your revision entity which is handled by the
@@ -1003,7 +1035,7 @@ If true, the result of the query will be a list of entities (which changed at re
1003
1035
If false, the result will be a list of three element arrays:
1004
1036
1005
1037
* the first element will be the changed entity instance.
1006
-
* the second will be an entity containing revision data (if no custom entity is used, this will be an instance of `DefaultRevisionEntity`).
1038
+
* the second will be an entity containing revision data (if no custom entity is used, this will be an instance of the <<envers-default-revision-entity,default revision entity type>>).
1007
1039
* the third will be the type of the revision (one of the values of the `RevisionType` enumeration: `ADD`, `MOD`, `DEL`).
1008
1040
1009
1041
`selectDeletedEntities`:: The second parameter specifies if revisions,
0 commit comments