Hibernate Types: Appendix A - Harnessing Hibernateby James Elliott, Timothy M. O'Brien, Ryan Fowler
This excerpt is from Harnessing Hibernate . This guide is an ideal introduction to Hibernate, the framework that lets Java developers work with information from a relational database easily and efficiently. Databases are a very different world than Java objects, and with Hibernate, bridging them is significantly easier. This new edition lets you explore the system, from download and configuration through a series of projects that demonstrate how to accomplish a variety of practical goals.
An entity is something with its own independent existence, regardless of whether it’s currently reachable by any object within a Java virtual machine. Entities can be retrieved from the database through queries, and they must be explicitly saved and deleted by the application. (If cascading relationships have been set up, the act of saving or deleting a parent entity can also save or delete its children, but this is still explicit at the level of the parent.)
Values are stored only as part of the persistent state of an entity. They have no independent existence. They might be primitives, collections, enumerations, or custom user types. Since they are entirely subordinated to the entity in which they exist, they cannot be independently versioned, nor can they be shared by more than one entity or collection.
Here is a smattering of information about the built-in types, showing how they relate Java classes to SQL column
types. We present samples of the variability between databases, but are
not trying to show every variant; check out the source code for all the
dialect implementations in org.hibernate.dialect for
the definitive details (look for
registerColumnType( ) calls).
Hibernate’s basic types fall into a number of groupings:
- Simple numeric and Boolean types
These correspond to the primitive Java types that represent numbers, characters, and Boolean values, or their wrapper classes. They get mapped to appropriate SQL column types (based on the SQL dialect in use). They are:
yes_no. The last two are alternate ways to represent a Boolean value within the database;
true_falseuses the values “T” and “F,” whereas
yes_nouses “Y” and “N.”
- String type
- Time types
timestampto map from
java.util.Date(and subclasses) to appropriate SQL types (e.g.,
timestampimplementation uses the current time within the Java environment; you can use the database’s notion of the current time instead by using
If you prefer working with the more convenient
java.util.Calendarclass, there is no need to translate to and from
Datevalues in your own code; you can map it directly with
calendar(which stores the date and time as a
calendar_date(which considers only the date, as a
- Arbitrary precision numeric
The Hibernate type
big_decimalprovides a mapping between
BigDecimalto the appropriate SQL type (usually
NUMERIC, but Oracle uses
BIGINT, but Informix calls it
INT8and Oracle again uses
- Localization values
currencyare stored as strings (
VARCHAR2, as noted above), and mapped to the
Currencyclasses in the java.util package.
Currencyare stored using their ISO codes, while
TimeZoneis stored using its ID property.
- Class names
- Byte arrays
- Any serializable object
serializablecan be used to map any serializable Java object into a SQL binary column. This is the fallback type used when attempting to persist an object that doesn’t have a more specific appropriate mapping (and for which you do not want to implement a
UserTypecustom mapping; see the next section). The SQL column type is the same as is used for
binary, described later.
- JDBC large objects
clobprovide mappings for the
Clobclasses in the java.sql package. If you are dealing with truly large values, your best bet is to declare the properties as either
Clob—even though this introduces an explicit JDBC dependency to your data object, it easily allows Hibernate to leverage JDBC features to lazily load the property value only if you need it.
If you are not worried that the data is too huge, you can spare yourself this direct JDBC interface, declare the property type as
byte[ ], and map it using
binary. These correspond to SQL column types of
BYTEAin PostgreSQL), respectively, and the values are loaded immediately into the properties when the object is loaded.
In addition to mapping your objects as entities, you can also create classes that are mapped to the database as values within other entities, without their own independent existence. This can be as simple as changing the way an existing type is mapped (because you want to use a different column type or representation), or as complex as splitting a value across multiple columns.
Although you can do this on a case-by-case basis within your mapping
documents, the principle of avoiding repeated code argues for
encapsulating types you use in more than one place into an actual reusable
class. Your class will implement either
technique is illustrated in Chapter 6.
This is also how you map Java 5’s
enum types (and
hand-coded instances of the type-safe enumeration pattern in from previous
Java versions). You can use a single, reusable custom type mapping for all
enumerations, as discussed in Chapter 6.
This final kind of mapping is very much a free-for-all. Essentially, it allows you to map references to any of your other mapped entities interchangeably. This is done by providing two columns, one which contains the name of the table to which each reference is being made, and another which provides the ID within that table of the specific entity of interest.
You can’t maintain any sort of foreign key constraints in such a loose relationship. It’s rare to need this kind of mapping at all. One situation in which you might find it useful is if you want to maintain an audit log that can contain actual objects. The reference manual also mentions web application session data as another potential use, but that seems unlikely in a well-structured application.
The following table shows each of the type classes in the
org.hibernate.types package, along with the type name
you would use for it in a mapping document, the most common SQL type(s) used in columns storing
mapped values, and any relevant comments about its purpose. In many cases,
more detailed discussion can be found earlier. To save space, the
Type” that appears at the end of each
class name has been removed, except in the case of the
Type interface implemented by all the
There is also a
TypeFactory class which provides assistance in building the right
Type implementation for a given need, such as when
parsing a type name in a mapping document. Reading its source is
If you enjoyed this excerpt, buy a copy of Harnessing Hibernate .