Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Teneo/Hibernate/Auditing"
| Line 10: | Line 10: | ||
Auditing can be enabled by calling setAuditing(true) on the datastore or setting the enable auditing option to true (see next section). To prevent auditing of specific types you can use the @NoAuditing annotation. Set this annotation in the EMF EAnnotation of the EClass using source 'teneo.jpa' and key 'value'. | Auditing can be enabled by calling setAuditing(true) on the datastore or setting the enable auditing option to true (see next section). To prevent auditing of specific types you can use the @NoAuditing annotation. Set this annotation in the EMF EAnnotation of the EClass using source 'teneo.jpa' and key 'value'. | ||
| + | |||
| + | == Audit Entries == | ||
| + | |||
| + | When auditing is enabled then each database action on an entity is persisted in a separate table. Each EClass will store its audit entries in a separate table. Teneo will store three types of events: ADD, UPDATE and DELETE. Teneo provides an api to retrieve the audit entries, this is described in more detail below. | ||
== Auditing Options == | == Auditing Options == | ||
| + | |||
| + | Teneo has many [[Teneo/Hibernate/Configuration_Options|configuration options]], three options are specific for auditing: | ||
| + | * ENABLE_AUDITING (teneo.mapping.auditing.enable): default is false, enables auditing if set to "true" | ||
| + | * AUDITING_ENTITY_PREFIX (teneo.naming.auditing.entity.prefix): defines the prefix which is set before the EClass name, this is used to compute the entity name and the table name used to store auditing entries. | ||
| + | * AUDITING_ENTITY_PREFIX (teneo.naming.auditing.entity.prefix): defines the prefix which is set before the EClass name, this is used to compute the entity name and the table name used to store auditing entries. | ||
== Retrieving Audit Entries == | == Retrieving Audit Entries == | ||
Revision as of 19:05, 2 November 2012
Contents
Teneo supports auditing (from November 2012), a summary of the functionality:
- auditing can be enabled for specific types
- earlier versions of objects can be retrieved
- possible to navigate/iterate over the history of an object
- query for version history using attribute and ereference values
Enable auditing
Auditing can be enabled by calling setAuditing(true) on the datastore or setting the enable auditing option to true (see next section). To prevent auditing of specific types you can use the @NoAuditing annotation. Set this annotation in the EMF EAnnotation of the EClass using source 'teneo.jpa' and key 'value'.
Audit Entries
When auditing is enabled then each database action on an entity is persisted in a separate table. Each EClass will store its audit entries in a separate table. Teneo will store three types of events: ADD, UPDATE and DELETE. Teneo provides an api to retrieve the audit entries, this is described in more detail below.
Auditing Options
Teneo has many configuration options, three options are specific for auditing:
- ENABLE_AUDITING (teneo.mapping.auditing.enable): default is false, enables auditing if set to "true"
- AUDITING_ENTITY_PREFIX (teneo.naming.auditing.entity.prefix): defines the prefix which is set before the EClass name, this is used to compute the entity name and the table name used to store auditing entries.
- AUDITING_ENTITY_PREFIX (teneo.naming.auditing.entity.prefix): defines the prefix which is set before the EClass name, this is used to compute the entity name and the table name used to store auditing entries.
Retrieving Audit Entries
By Object
Query
Iterating over version history
Limitations
Auditing does not work in combination with specific functionality:
- EmbeddedId is not supported, this is neither supported with Hibernate envers.
- EAV mapping can not be combined with auditing. This can be solved but requires some work, please ask on the newsgroup if relevant for your case.
- Embeddable/Embedded works fine but only if annotated in the model, so not using a separate xml/hbm mapping file. This can be solved but needs some work, please ask on the newsgroup if relevant for your case.
- the delete audit entry does not contain any collection values