Currently, we are using the version 3.6.9.Final for all our Hibernate libraries, including Hibernate Envers for our audit revisions.
We want to move to the 4.1.8.Final version (to use the #Audited(withModifiedFlag = true) among others things), but only for Hibernate Envers. Unfortunately, it does not seem to work. When I modify an #Audited entity, Envers does not save the revision.
Maybe it's due to the definition of the listeners? With 3.6.9, I set the following properties in my hibernate.properties file:
hibernate.ejb.event.post-insert=org.hibernate.ejb.event.EJB3PostInsertEventListener,org.hibernate.envers.event.AuditEventListener
hibernate.ejb.event.post-update=org.hibernate.ejb.event.EJB3PostUpdateEventListener,org.hibernate.envers.event.AuditEventListener
hibernate.ejb.event.post-delete=org.hibernate.ejb.event.EJB3PostDeleteEventListener,org.hibernate.envers.event.AuditEventListener
hibernate.ejb.event.pre-collection-update=org.hibernate.envers.event.AuditEventListener
hibernate.ejb.event.pre-collection-remove=org.hibernate.envers.event.AuditEventListener
hibernate.ejb.event.post-collection-recreate=org.hibernate.envers.event.AuditEventListener
As far as I know, the version 4 of Envers does not need these declarations anymore. Without them, I get no error, but the revision are not created. I can't set these declarations back, as the classes are not the same between v3 and v4 (especially org.hibernate.envers.event.AuditEventListener that does not exist anymore).
So is there a way to make it work?
No, that is not possible, you must use the same Hibernate and Envers versions.
Related
Hi my question is not technical. I want to know if hibernate 5 supports XML based entity mapping or not.
My requirement is like below :
I want a backend on Jersey-Hibernate. My front end is Android application.
I want to keep my Entity POJOs in a common project such that they will be shared by both app and server. Gson will serialize/deserialize both side.
But because android application doesn't support all java library in compilation, I don't want my common(POJO) depending on some library; In this case hibernate annotations. So I am planning to use XML based configuration.
Hibernate 5 supports both the legacy HBM mappings as well as the JPA XML mappings too. However, HBM mappings are no longer the recommended approach to map entities. As illustrated in the new User Guide, all examples make use of annotations.
There are more features provided by Hibernate-specific annotations than it is the case with HBM mappings. In Hibernate 6, it is planned to add an extension mechanism to the JPA XML mappings, therefore HBM mappings are deprecated.
Since you are migrating to Hibernate 5, it's a good idea to migrate from HBM to annotations too.
Yes, according to documentation (where authors recommended using annotations for mapping) is said that xml mapping is still possible: docs
So on - you can still us *.hbm.xml for entity mapping.
EDIT: ofc I mean *.hbm.xml
I am using Hibernate in our projects and annotation based configuration for Hibernate Domain Pojo Objects. For Annotations based configuration we have two options
JPA based annotations using javax.persistence.*
Use Hibernate Native Annotations org.hibernate.annotations.*
Currently we use JPA based annotation configuration for our POJO files and Hibernate native API like SessionFactory, Session, etc to open session and perform DB operations.
I have these questions:
Is there any problem mixing both JPA annotations and use Hibernate
native API?
This link explains one such issue
(cascade-jpa-hibernate-annotation-common-mistake)
Please provide your expertise, which type of annotations to use
JPA
Hibernate native
Mix both of them?
Hibernate provides one of the JPA implementations. If you use purely JPA in your code, you are free to change to a different implementation if a requirement arises. For example, EclipseLink/TopLink and OpenJPA are implementations which may be required for a different customer. A comprehensive list of implementations is here.
If you are compelled to use any exotic features provided by hibernate which are not in JPA specification, you should go for hibernate specific APIs in your code base. A related discussion from hibernate forum here.
We mixed some of these annotations since with the version of hibernate we were working those days, some features were not available on the JPA spec at that time. For instance to store a boolean value as a 'Y' or 'N' on th DB you have hibernate types you can use. But no such feature was available with the JPA spec at that time. I do not know about the status now. Also for orphan removal also those days JPA did not have the feature, but now i belive they provide an attribute called orphanRemoval on your cascade options. Also you have certain features such as #BatchSize to increase fetching performance with respect to bags. I am unaware if such features are available on the JPA spec yet.
In my experience, mixing and matching plus points from both would be beneficial given that you have no need of switching from one ORM to another.
To keep it short and sweet:
There is hibernate-commons-annotations 4.1.0-Final and hibernate-annotations 3.5.6-Final.
I'm a nub, what's the difference between them, and do I need them both?
Trying to "avoid" JPA and by that I mean using the JPA 2.0 standards embedded within Hibernate.
Thanks!
Previously, hibernate-annotations was released and versioned from hibernate core. But from version 3.5 and up it is included with hibernate core. And for some reason it was still released from 3.5.0 to 3.5.6 but you do not need it anymore.
And coming to hibernate-commons-annotations, it is a utility project used by annotations based hibernate sub-projects. It is used by other hibernate projects like hibernate-search and thus is maintained as a separate project and it is a compile time dependency for hibernate-core v3.6.0 and up.
Source 1
Source 2
Hibernate Commons Annotations is "Utility project for annotation handling", as said for example here. It does not contain such API that normal user of Hibernate should use.
Hibernate annotations contained persistence mapping annotations and related code. Nowadays it is merged to Hibernate core.
If you really want to avoid JPA (1/2) that is easily done by not using classes from javax.persistence package or from its subpackages. If you want opposite, use javax.persistence and avoid org.hibernate packages where possible.
Good guide to get started with Hibernate can be found from http://docs.jboss.org/hibernate/orm/4.1/quickstart/en-US/html_single/. It also tells which libraries are needed always and which ones are optional.
Reference documentation contains plenty of advices about using JPA instead of deprecated legacy Hibernate annotations.
Currently I have following scenario with my project :
Implemented Hibernate Configuration files (xml) mapping
Database doesn't have any FK relationship yet
So Now I wanna know that what are the things I need to keep in mind before migrating from hibernate xml configuration to hibernate annotations.
One more thing I wanna specify here is right now with my db i don't have any kind of FK relationship defined....
So obviously I will be applying FK first and then start migrating to annotations...
With this scenario Can anybody have any specific suggestion that I should follow ?
Thanks in advance...
Be very careful. Where I work we do everything with annotations so there shouldn't be any specific limitations as far as I can foretell.
It might be wise to migrate a logic chunk of your code at a time if at all possible. But basically it's just painstakingly running through your code and copying everything from the cofnig xml to your entity classes.
I have entities that required versioning support and from time to time, i will need to retrieve old version of the entity . should i just use
options available
1. http://stackoverflow.com/questions/762405/database-data-versioning
2. jboss envers (can this be used on any web server,tomcat,jetty, appengine) ?
3. any similar library like jboss envers that ease to do versioning?
JBoss Envers can be used always when you're using Hibernate as the persistence provider. It's actually bundled with the new Hibernate 3.5. Envers is a an excellent tool, but I has one drawback - you can version only entities that aggregate versioned entities. This means that if you want to version Entity A and it has fields of types B and C, which are also entities - B and C should be versioned by envers as well - if your entities have a tight coupling(which is bad design, but is fairly possible) you'll have to version the whole project and there is some overhead to that.
We personally opted for a lighter custom versioning solution after we investigated Envers, but if it fits your bill - you should definitely use it. I'm not aware of other tools offering its capabilities.