I am in the process of migrating a project from 5.6 to Hibernate 6.3 and I am surprised by some of the changes. I will list them in order:
- Why Type.class now doesn’t have the nullSafeGet(ResultSet rs, int position, SharedSessionContractImplementor session, Object owner) method, although UserType.class kept it?
- Why do StandardBasicTypes now contain instances of BasicTypeReference instead of AbstractStandardBasicType inheritors? As far as I understand from User Guide, AbstractStandardBasicType inheritors (e.g. StringType) have been replaced by NamedBasicTypeImpl. If I understand the meaning correctly, why are not their instances in StandardBasicTypes?
- Why does CustomType now require explicit passing of TypeConfiguration? It’s not very convenient to get it to create custom types.
Read the 6.0 migration guide which will answer a few of your questions.
Overall, the design simply changed from
BasicType driving the binding/extraction to fully splitting up the responsibility into
JdbcType. This means
BasicType is not special anymore and that instances of such types are registered in the
BasicTypeRegistry under the tuple of
You’re not supposed to create
CustomType yourself. This is just a contract that Hibernate ORM uses internally to wrap the
UserType into this type system, so that you don’t have to implement so many methods.
A lot has changed in ORM 6, so maybe you should start rethinking what you are doing and learn the new features to understand if you can rather use these to implement what you desire.
Thank you for your reply, I generally understand the gist of the changes you have written ( I have read the 6.0 migration guide), however the individual points present issues.
The one I wrote about NamedBasicTypeImpl. Despite the fact that this class, as stated in the migration guide, takes the role of BasicType implementations, it doesn’t have for example the nullSafeGet method I need, which takes an argument of ResultSet type. Why is it missing now? Previously, any BasicType had this variant nullSafeGet
BasicType is not in charge of binding/extraction anymore. The
JdbcType along with the
JavaType is now responsible for this.
So if you want to adjust how Hibernate ORM interacts with
ResultSet, you will have to either override an existing
JdbcType or register a new one. You can either force a specific
JdbcType by using e.g.
@JdbcType(MyJdbcType.class) on an entity attribute, or register it under a type code, which is just a unique integer value usually corresponding to constants in
org.hibernate.type.SqlTypes. Under that same code you can also register a custom
DdlType and all of that through e.g. a