Hibernate.orgCommunity Documentation
Hibernate Core also offers integration with some external modules/projects. This includes Hibernate Validator the reference implementation of Bean Validation (JSR 303) and Hibernate Search.
Bean Validation standardizes how to define and declare domain model level constraints. You can, for example, express that a property should never be null, that the account balance should be strictly positive, etc. These domain model constraints are declared in the bean itself by annotating its properties. Bean Validation can then read them and check for constraint violations. The validation mechanism can be executed in different layers in your application without having to duplicate any of these rules (presentation layer, data access layer). Following the DRY principle, Bean Validation and its reference implementation Hibernate Validator has been designed for that purpose.
The integration between Hibernate and Bean Validation works at two levels. First, it is able to check in-memory instances of a class for constraint violations. Second, it can apply the constraints to the Hibernate metamodel and incorporate them into the generated database schema.
Each constraint annotation is associated to a validator implementation responsible for checking the constraint on the entity instance. A validator can also (optionally) apply the constraint to the Hibernate metamodel, allowing Hibernate to generate DDL that expresses the constraint. With the appropriate event listener, you can execute the checking operation on inserts, updates and deletes done by Hibernate.
When checking instances at runtime, Hibernate Validator returns information about constraint violations in a set of ConstraintViolations. Among other information, the ConstraintViolation contains an error description message that can embed the parameter values bundle with the annotation (eg. size limit), and message strings that may be externalized to a ResourceBundle.
To enable Hibernate's Bean Validation integration, simply add a Bean Validation provider (preferably Hibernate Validation 4) on your classpath.
By default, no configuration is necessary.
The Default group is validated on entity insert and update and the database model is updated accordingly based on the Default group as well.
You can customize the Bean Validation integration by setting the validation mode. Use the javax.persistence.validation.mode property and set it up for example in your persistence.xml file or your hibernate.cfg.xml file. Several options are possible:
auto (default): enable integration between Bean Validation and Hibernate (callback and ddl generation) only if Bean Validation is present in the classpath.
none: disable all integration between Bean Validation and Hibernate
callback: only validate entities when they are either inserted, updated or deleted. An exception is raised if no Bean Validation provider is present in the classpath.
ddl: only apply constraints to the database schema when generated by Hibernate. An exception is raised if no Bean Validation provider is present in the classpath. This value is not defined by the Java Persistence spec and is specific to Hibernate.
You can use both callback and ddl together by setting the property to callback, dll
<persistence ...>
<persistence-unit ...>
...
<properties>
<property name="javax.persistence.validation.mode"
value="callback, ddl"/>
</properties>
</persistence-unit>
</persistence>
This is equivalent to auto except that if no Bean Validation provider is present, an exception is raised.
If you want to validate different groups during insertion, update and deletion, use:
javax.persistence.validation.group.pre-persist: groups validated when an entity is about to be persisted (default to Default)
javax.persistence.validation.group.pre-update: groups validated when an entity is about to be updated (default to Default)
javax.persistence.validation.group.pre-remove: groups validated when an entity is about to be deleted (default to no group)
org.hibernate.validator.group.ddl: groups considered when applying constraints on the database schema (default to Default)
Each property accepts the fully qualified class names of the groups validated separated by a comma (,)
Exemple 23.1. Using custom groups for validation
<persistence ...>
<persistence-unit ...>
...
<properties>
<property name="javax.persistence.validation.group.pre-update"
value="javax.validation.group.Default, com.acme.group.Strict"/>
<property name="javax.persistence.validation.group.pre-remove"
value="com.acme.group.OnDelete"/>
<property name="org.hibernate.validator.group.ddl"
value="com.acme.group.DDL"/>
</properties>
</persistence-unit>
</persistence>
You can set these properties in hibernate.cfg.xml, hibernate.properties or programmatically.
If an entity is found to be invalid, the list of constraint violations is propagated by the ConstraintViolationException which exposes the set of ConstraintViolations.
This exception is wrapped in a RollbackException when the violation happens at commit time. Otherwise the ConstraintViolationException is returned (for example when calling flush(). Note that generally, catchable violations are validated at a higher level (for example in Seam / JSF 2 via the JSF - Bean Validation integration or in your business layer by explicitly calling Bean Validation).
An application code will rarely be looking for a ConstraintViolationException raised by Hibernate. This exception should be treated as fatal and the persistence context should be discarded (EntityManager or Session).
Hibernate uses Bean Validation constraints to generate an accurate database schema:
@NotNull leads to a not null column (unless it conflicts with components or table inheritance)
@Size.max leads to a varchar(max) definition for Strings
@Min, @Max lead to column checks (like value <= max)
@Digits leads to the definition of precision and scale (ever wondered which is which? It's easy now with @Digits :) )
These constraints can be declared directly on the entity properties or indirectly by using constraint composition.
For more information check the Hibernate Validator reference documentation.
Full text search engines like Apache Lucene™ are a very powerful technology to bring free text/efficient queries to applications. If suffers several mismatches when dealing with a object domain model (keeping the index up to date, mismatch between the index structure and the domain model, querying mismatch...) Hibernate Search indexes your domain model thanks to a few annotations, takes care of the database / index synchronization and brings you back regular managed objects from free text queries. Hibernate Search is using Apache Lucene under the cover.
Hibernate Search integrates with Hibernate Core transparently provided that the Hibernate Search jar is present on the classpath. If you do not wish to automatically register Hibernate Search event listeners, you can set hibernate.search.autoregister_listeners to false. Such a need is very uncommon and not recommended.
Check the Hibernate Search reference documentation for more information.
Copyright © 2004 Red Hat, Inc.