...enable easy versioning of persistent JPA classes. All that you have to do is annotate your persistent class or some of its properties, that you want to version, with @Versioned. For each versioned entity, a table will be created, which will hold the history of changes made to the entity. You can then retrieve and query historical data without much effort.Envers works wherever Hibernate can run as Envers works with Hibernate and Hibernate Entity Manager. For example Envers can run in a standalone environment, inside an application server, with JBoss Seam or Spring. The current release of Envers offers a number of features:
- versioning of basic properties (strings, integers, longs...)
- versioning of embedded components, which are composed of basic properties
- versioning of classes with simple, composite and embedded ids
- versioning of one-to-one uni- (only on the owning side) and bi-directional relations
- versioning of one-to-many uni- (only on the owning side) and bi-directional relations
- support for secondary tables
- logging data for each revision using a "revision entity"
- querying historical data
Imagine you have a Person and Address entities in a bidirectional many-to-one relation (each person has exactly one address and many people can live at the same address). Now you change an address of a person - hence, the content of the collection of persons for the new and old addresses change. In the preview and beta versions of Envers, no revision will be generated for the Addresses (only for Person), as data in the database tables is not modified (but data in the java beans is modified). Now, however, a revision will be created for all three entities.If for some reason that functionality is not desired it can be disabled by making a small configuration change,
<property value="false" name="org.jboss.envers.revisionOnCollectionChange"/>
Future versions of Envers will include the ability, version arbitrary relationships, store only diffs between revisions (helping to save space), and more. Envers is a fairly new project and hasn't gained a lot of traction yet but it is certainly worth keeping an eye on. For additional information try the following resources:
Community comments
An old idea
by Billy Newport,
Re: An old idea
by Adam Warski,
EclipseLink's Historical Sessions
by Ralph Poellath,
Re: EclipseLink's Historical Sessions
by Adam Warski,
An old idea
by Billy Newport,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've seen this pattern many times over the years but what tends to cause issues with this system is every update/remove becomes an insert and high speed inserting can be a challenge for most databases on the market. Databases are better at updating usually and performance can become an issue as a result. It's a cool idea though.
EclipseLink's Historical Sessions
by Ralph Poellath,
Your message is awaiting moderation. Thank you for participating in the discussion.
How does this compare to EclipseLink's Historical Sessions?
Re: EclipseLink's Historical Sessions
by Adam Warski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hello,
from what I've read, EclipseLink first of all uses another JPA provider :) (Envers uses Hibernate)
Then, it offers you two options:
- use Oracle 9i which has versioning capabilities built-in
- configure HistoryPolicy to read data from a schema that _you_ design
With Envers, you don't need to be concerned with designing the schema. All necessary tables are generated automatically, you just specify that you want your entities versioned. This has its bad sides: less flexibility, as the way historical data is stored is fixed, and good sides: really easy to do if you want to version many entities, with almost no additional work. You can of course use all databases supported by Hibernate (almost all: as long as they support subqueries).
Re: An old idea
by Adam Warski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hello,
that's true, when there really are lots and lots of updates, the inserts may be a bottleneck. But I designed Envers mainly with non-very-fast changing data in mind.
Adam