While trying to persist an entity with:
an id generated with strategy GenerationType.TABLE
a field annotated with @javax.validation.constraints.NotNull
a null value for that field
I was expecting that:
the entityManager.persist() throws a javax.validation.ConstraintViolationException
the transaction to be marked as rollback-only
(Those expectations are based on jpa 2.0 specifications)
But the current behavior is:
entityManager.persist() don't throw any exception
transaction is not marked as rollback only
later, the transaction.commit() throws a RollbackException
If the entity have an id using the default id generation strategy (i.e. annotated only with @GeneratedValue @Id) everything works as expected.
The attached project contains 2 tests : one successful for an entity with default id generation strategy and one failing for an entity with table genarated id startegy
there is a related question on SO : http://stackoverflow.com/questions/14978291/hibernate-not-following-jpa-specifications-when-combined-with-bean-validation-ap
H2 in memory database 1.3.170
Same issue happens even when the id is generated with jpa- sequence generator. However, works fine when @GeneratedValue(strategy=GenerationType.IDENTITY) and @GeneratedValue(strategy=GenerationType.AUTO) are used.
I wonder if it is something wrong with our code. Any help would be greatly appreciated.
The problem is that em.persist is not calling the pre-persist callbacks. Hibernate delays the execution of these callbacks until em.flush() is called. Even though this might sound counterintuative initially, it makes more sense if you think about whole object graphs and cascading operations. Flush is when Hibernate ORM identifies all the entities that have been changed and need database actions.
Regarding the spec, it is vague enough in this regards to allow for this behaviour.
Bulk closing rejected tickets in "resolved" state.