We Keep Coding

Issue with implementing UUIDs with Hibernate Envers

Our application is using Hibernate envers to provide auditing on updates to entities. Whenever an entity is modified (or inserted), a backup of the entity (i.e. the table’s row) is saved to an "AUD" table.
This provides us with auditing functionality (which is a requirement) and has been working well up until now. But we are now facing issues because we need to migrate to using UUIDs as data keys. Our application will be run in a distributed environment with limited or intermittent internet access, so we will be using SymmetricDS to manage data synchronisation, and UUIDs will allow us to do that without causing data conflicts.
The problem we are facing with Hibernate envers is that the RevisionNumber annotation that is used to add the REV number into the AUD table will only work with int, Integer, long and Long identifiers.
We have implemented a class called AuditRevision (that extends the Hibernate class DefaultRevisionEntity) with some extra attributes, and have implemented an AuditRevisionListener (that implements Hibernate’s EntityTrackingRevisionListener) to manage saving and updating the extra data. However, in order to allow us to save revisions using UUIDs instead of an auto incrementing id, we rewrote AuditRevision so that it doesn't extend DefaultRevisionEntity and instead defines its own UUID id.
We then saw the following error in our application:
Caused by: org.hibernate.MappingException: The field annotated with #RevisionNumber must be of type int, Integer, long or Long
at org.hibernate.envers.configuration.internal.RevisionInfoConfiguration.searchForRevisionInfoCfgInProperties(RevisionInfoConfiguration.java:224)
at org.hibernate.envers.configuration.internal.RevisionInfoConfiguration.searchForRevisionInfoCfg(RevisionInfoConfiguration.java:304)
at org.hibernate.envers.configuration.internal.RevisionInfoConfiguration.configure(RevisionInfoConfiguration.java:347)
at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:119)
at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:312)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1859)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:852)
... 41 more
We are unsure how to continue. If we can't replace the long primary key of the AuditRevision table to use a UUID id, we could add a UUID (or another id or key) to the AuditRevision table and then use it along with the auto increment id as a composite key. The AUD tables will then need to reference the UUID, which we thought we could manage using a database trigger because we don't have control over the AUD tables.
Another option is that we could also rewrite the Hibernate envers library or fork their code and make the necessary modifications to support UUID.
Does anyone have any experience of this problem? How would you solve it?
We are using Hibernate 4.3.7.Final with a MySQL 5.7 database

Create Table from generated classes

I have generated the representations for my database-model in jooq.
Can I use this to recreate the Database?.
createTable(org.jooq.Table<?> table) wants me to specify the columns.
Ideally when the schema changes, i would just update the jooq representation and when another user installs it it would automatically create the right schema.

There is a pending feature request for this kind of functionality:
https://github.com/jOOQ/jOOQ/issues/3160
But as of jOOQ 3.7, this isn't yet possible. The main challenge is the fact that the generated schema meta information will always lack important pieces (e.g. vendor-specific storage clauses), so this kind of functionality is good for simple databases or test databases at best.

JPA 2: Benefits of #TableGenerator

What are the benefit of #TableGenerator Technique to generate the primary keys?
Why we use this technique and how to fetch the data using third table that use to store the sequence name and value of generator?

From the link. http://en.wikibooks.org/wiki/Java_Persistence/Identity_and_Sequencing#Table_sequencing
There are several strategies for generating unique ids. Some strategies are database agnostic and others make use of built-in databases support.
JPA provides support for several strategies for id generation defined through the GenerationType enum values: TABLE, SEQUENCE and IDENTITY.
The choice of which sequence strategy to use is important as it affects performance, concurrency and portability.
So the choice of using table generators frees you from using database specific features. This makes it easy to migrate the database to some other db provider later on.
So the decision should be made based on whether you want to later on migrate database providers, how much performance you will sacrifice for that etc.

ORM Technologies vs JDBC?

My question is regarding ORM and JDBC technologies, on what criteria would you decide to go for an ORM technology as compared to JDBC and other way round ?
Thanks.

JDBC
With JDBC, developer has to write code to map an object model's data representation to a relational data model and its corresponding database schema.
With JDBC, the automatic mapping of Java objects with database tables and vice versa conversion is to be taken care of by the developer manually with lines of code.
JDBC supports only native Structured Query Language (SQL). Developer has to find out the efficient way to access database, i.e. to select effective query from a number of queries to perform same task.
Application using JDBC to handle persistent data (database tables) having database specific code in large amount. The code written to map table data to application objects and vice versa is actually to map table fields to object properties. As table changed or database changed then it’s essential to change object structure as well as to change code written to map table-to-object/object-to-table.
With JDBC, it is developer’s responsibility to handle JDBC result set and convert it to Java objects through code to use this persistent data in application. So with JDBC, mapping between Java objects and database tables is done manually.
With JDBC, caching is maintained by hand-coding.
In JDBC there is no check that always every user has updated data. This check has to be added by the developer.
HIBERNATE.
Hibernate is flexible and powerful ORM solution to map Java classes to database tables. Hibernate itself takes care of this mapping using XML files so developer does not need to write code for this.
Hibernate provides transparent persistence and developer does not need to write code explicitly to map database tables tuples to application objects during interaction with RDBMS.
Hibernate provides a powerful query language Hibernate Query Language (independent from type of database) that is expressed in a familiar SQL like syntax and includes full support for polymorphic queries. Hibernate also supports native SQL statements. It also selects an effective way to perform a database manipulation task for an application.
Hibernate provides this mapping itself. The actual mapping between tables and application objects is done in XML files. If there is change in Database or in any table then the only need to change XML file properties.
Hibernate reduces lines of code by maintaining object-table mapping itself and returns result to application in form of Java objects. It relieves programmer from manual handling of persistent data, hence reducing the development time and maintenance cost.
Hibernate, with Transparent Persistence, cache is set to application work space. Relational tuples are moved to this cache as a result of query. It improves performance if client application reads same data many times for same write. Automatic Transparent Persistence allows the developer to concentrate more on business logic rather than this application code.
Hibernate enables developer to define version type field to application, due to this defined field Hibernate updates version field of database table every time relational tuple is updated in form of Java class object to that table. So if two users retrieve same tuple and then modify it and one user save this modified tuple to database, version is automatically updated for this tuple by Hibernate. When other user tries to save updated tuple to database then it does not allow saving it because this user does not have updated data.

Complexity.
ORM If your application is domain driven and the relationships among objects is complex or you need to have this object defining what the app does.
JDBC/SQL If your application is simple enough as to just present data directly from the database or the relationships between them is simple enough.
The book "Patterns of enterprise application architecture" by Martin Fowler explains much better the differences between these two types:
See: Domain Model and Transaction Script

I think you forgot to look at "Functional Relational Mapping"
I would sum up by saying:
If you want to focus on the data-structures, use an ORM like JPA/Hibernate
If you want to shed light on treatments, take a look at FRM libraries: QueryDSL or Jooq
If you need to tune your SQL requests to specific databases, use JDBC and native SQL requests
The strengh of various "Relational Mapping" technologies is portability: you ensure your application will run on most of the ACID databases.
Otherwise, you will cope with differences between various SQL dialects when you write manually the SQL requests.
Of course you can restrain yourself to the SQL92 standard (and then do some Functional Programming) or you can reuse some concepts of functionnal programming with ORM frameworks
The ORM strenghs are built over a session object which can act as a bottleneck:
it manages the lifecycle of the objects as long as the underlying database transaction is running.
it maintains a one-to-one mapping between your java objects and your database rows (and use an internal cache to avoid duplicate objects).
it automatically detects association updates and the orphan objects to delete
it handles concurrenty issues with optimistic or pessimist lock.
Nevertheless, its strengths are also its weaknesses:
The session must be able to compare objects so you need to implements equals/hashCode methods
But Objects equality must be rooted on "Business Keys" and not database id (new transient objects have no database ID!).
However, some reified concepts have no business equality (an operation for instance).
A common workaround relies on GUIDs which tend to upset database administrators.
The session must spy relationship changes but its mapping rules push the use of collections unsuitable for the business algorithms.
Sometime your would like to use an HashMap but the ORM will require the key to be another "Rich Domain Object" instead of another light one...
Then you have to implement object equality on the rich domain object acting as a key...
But you can't because this object has no counterpart on the business world.
So you fall back to a simple list that you have to iterate on (and performance issues result from)
The ORM API are sometimes unsuitable for real-world use.
For instance, real world web applications try to enforce session isolation by adding some "WHERE" clauses when you fetch data...
Then the "Session.get(id)" doesn't suffice and you need to turn to more complex DSL (HSQL, Criteria API) or go back to native SQL
The database objects conflicts with other objects dedicated to other frameworks (like OXM frameworks = Object/XML Mapping).
For instance, if your REST services use jackson library to serialize a business object.
But this Jackson exactly maps to an Hibernate One.
Then either you merge both and a strong coupling between your API and your database appears
Or you must implement a translation and all the code you saved from the ORM is lost there...
On the other side, FRM is a trade-off between "Object Relational Mapping" (ORM) and native SQL queries (with JDBC)
The best way to explain differences between FRM and ORM consists into adopting a DDD approach.
Object Relational Mapping empowers the use of "Rich Domain Object" which are Java classes whose states are mutable during the database transaction
Functional Relational Mapping relies on "Poor Domain Objects" which are immutable (so much so you have to clone a new one each time you want to alter its content)
It releases the constraints put on the ORM session and relies most of time on a DSL over the SQL (so portability doesn't matter)
But on the other hand, you have to look into the transaction details, the concurrency issues
List<Person> persons = queryFactory.selectFrom(person)
.where(
person.firstName.eq("John"),
person.lastName.eq("Doe"))
.fetch();

It also depends on the learning curve.
Ebean ORM has a pretty low learning curve (simple API, simple query language) if you are happy enough with JPA annotations for mapping (#Entity, #Table, #OneToMany etc).

hibernate #GeneratedValue correct?

I set my entity property
#GeneratedValue
Long id;
and I able to generate id for the entity in database. My question is why all the entities are sharing the same incremental number? aren't each table should start counting from zero?

It depends on the underlying database.
GenerationType is AUTO by default, and Hibernate chooses one of the three variants depending on the database. If you want to use one in particular, set it as attribute of #GeneratedValue

This is database-dependent. JPA implementations use different ID generators depending on which database system they're using. For example, with Oracle, a single sequence will be created, and that sequence will be used to generate IDs for all entity types. By default, it will not create a sequence for each entity, since there's usually no reason to. The same logic applies to other database systems that use sequences rather than auto-increment columns.
I'm not 100% sure if the JPA API lets you change this behaviour, but I know that Hibernate annotations do. However, you haven't told us which database you're using or which JPA implementation you're using, so I can't give you much more advice than that.