Envers is an open-source project from JBoss which aims to provide easy versioning of persistent JPA classes. InfoQ provided information about the first GA release, 1.0.0, back in July of 2008. Since then Envers 1.1.0 was released which provided several new features.
The primary focus for the 1.1.0 release was the addition of support for persistent collections. Adam Warski, founder of Envers, described the new feature:
You can now version any relation, collections of “simple” types, maps, etc. All collection mappings defined by JPA are now supported, and most of what Hibernate additionally allows also.
The latest release also included some other improvements and bug fixes, as well as updates to the demos. With the continuing improvements to Envers, there is other news which was the source for this news item. On October 30, 2008 Envers officially became a module of Hibernate. The Envers website, documentation and forum will stay at there original home page for some time to come. The primary major changes were listed by Adam Warski on his blog:
- The code is now in the hibernate-core repository (envers module). There will be no more commits to the old repository.
- Issue tracking moved to Hibernate’s JIRA. All open issues from the old JIRA have been moved there.
- Envers is now built using maven2, which replaces the old ant build
It's exciting times for Adam Warski and other contributors to Envers. The move to the Hibernate family should aid in the continued development of the Envers module and the further expansion into developers toolbelts when it comes to persisting Java objects.
Community comments
How does envers handle circular references?
by peter lin,
Re: How does envers handle circular references?
by Adam Warski,
Re: How does envers handle circular references?
by peter lin,
Re: How does envers handle circular references?
by Adam Warski,
Re: How does envers handle circular references?
by peter lin,
How does envers handle circular references?
by peter lin,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm curious, how does envers handles a situation where there's circular references? For example, say we have a model with bi-directional references like this.
Person - has a collection of addresses
Address - has a reference to the person
How does envers know to skip a bidirectional reference and only traverse down the object graph and not back up.
Re: How does envers handle circular references?
by Adam Warski,
Your message is awaiting moderation. Thank you for participating in the discussion.
When saving changes, it's only needed to traverse 0 or 1 levels deep (depending on the settings).
When loading changes, there is a "first-level cache", so you always attempt to load each entity at a revision once.
Hope this answers your question :)
Adam
Re: How does envers handle circular references?
by peter lin,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for responding. I looked for envers design docs late last night and couldn't find any. I finally decided to read the code, but couldn't quite make out the overall design.
It sounds like the @versioned annotation gives users the ability to set the depth. I have another question, which I couldn't figure out from the website or forum.
Say I have a large object graph and all the entities in that graph are versioned. Here is a hypothetical model.
If I add a new ServiceCall, does it revision the entire graph in the global revision, or does it maintain a parts list?
thanks
peter
Re: How does envers handle circular references?
by Adam Warski,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hello,
no, only a new revision for ServiceCall will be generated. If the relation with ServiceHistory is bidirectional, and a certain configuation option is set, a revision for ServiceHistory will also be generated.
--
Adam
Re: How does envers handle circular references?
by peter lin,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sounds like Envers maintains a parts list. By that I mean does it keeps a list of all the records (id + version + timestamp) for each global version. I forgot to mention in the previous comment, the entire plan needs to be versioned including all the objects hanging off it. Is my interpretation correct or totally wrong.
thanks
peter