It is relatively easy for developers to create their own value types. For example, you might want to persist properties of type
VARCHAR columns. Hibernate does not provide a built-in type for this. But custom types are not limited to mapping a property (or collection element) to a single table column. So, for example, you might have a Java property
setName() of type
java.lang.String that is persisted to the columns
To implement a custom type, implement either
org.hibernate.CompositeUserType and declare properties using the fully qualified classname of the type. Check out
org.hibernate.test.DoubleStringType to see the kind of things that are possible.
<property name="twoStrings" type="org.hibernate.test.DoubleStringType">
Notice the use of
<column> tags to map a property to multiple columns.
UserVersionType interfaces provide support for more specialized uses.
You may even supply parameters to a
UserType in the mapping file. To do this, your
UserType must implement the
org.hibernate.usertype.ParameterizedType interface. To supply parameters to your custom type, you can use the
<type> element in your mapping files.
UserType can now retrieve the value for the parameter named
default from the
Properties object passed to it.
If you use a certain
UserType very often, it may be useful to define a shorter name for it. You can do this using the
<typedef> element. Typedefs assign a name to a custom type, and may also contain a list of default parameter values if the type is parameterized.
<typedef class="com.mycompany.usertypes.DefaultValueIntegerType" name="default_zero">
<property name="priority" type="default_zero"/>
It is also possible to override the parameters supplied in a typedef on a case-by-case basis by using type parameters on the property mapping.
Even though Hibernate's rich range of built-in types and support for components means you will very rarely need to use a custom type, it is nevertheless considered good form to use custom types for (non-entity) classes that occur frequently in your application. For example, a
MonetaryAmount class is a good candidate for a
CompositeUserType, even though it could easily be mapped as a component. One motivation for this is abstraction. With a custom type, your mapping documents would be future-proofed against possible changes in your way of representing monetary values.