| Comment: |
{quote}
Quick background.. JavaTypeDescriptor describes the Java type; SqlTypeDescriptor describes the database type. An ORM Type defines the coordination between the two. These ORM Types generally describe the Java type of a persistent attribute (singular or plural) as well as the index/map-key and element/map-value. ORM Type is broadly categorized by:
# ManagedType
## EmbeddableType
## IdentifiableType
## EntityType
# BasicType
# CollectionType
ManagedTypes and CollectionTypes are the same in that their interesting details and capabilities are kept on a separate group of contracts called "persisters" which they resolve as needed via the {{TypeConfiguration}} and expose to the Type holder. BasicTypes generally handle their interesting pieces themselves.
{quote}
Actually this might have to make it into Alpha1 as it gets to the heart of the new Type design especially as concerns resolution of a BasicType in the ORM Type sense ({{org.hibernate.type.spi.BasicType}}). The underlying design here is moving BasicType to more of a composition design rather than subclassing. Specifically a BasicType is made up of:
# JavaTypeDescriptor
# SqlTypeDescriptor
# MutabilityPlan
# Comparator
# javax.persistence.TemporalType (called "temporal precision") for ORM TemporalTypes
Specifying the individual components listed above via various mapping constructs - the end "accumulation" of those being a {{org.hibernate.type.spi.BasicTypeParameters}} reference to pass to {{org.hibernate.type.spi.BasicTypeRegistry#resolveBasicType}} which is how BasicTypes are resolved and cached during bootstrap based on a "registry key" which BasicType now exposes as well: {{BasicType#getRegistryKey}}. {{BasicTypeParameters}} exposes this common information regardless of the mapping source (singular attribute, collection element, etc) for resolution.
In terms of how that affects user migrating, it will effect them if they either:
# implement custom type via Type, BasicType, UserType or CompositeUserType - I think the ideal option here is to ask the implementors to make some minor changes in their implementation. The changes are pretty straight forward and referenced in the migration guide.
# use Type - generally this happens in relation to setting Query parameters. And getting ahold of one was not perfect the idea here is to maybe to continue to
The question above wrt continuing to support naming BasicTypes by name, I more just mean that I think we should shift the meaning of that to interpret the historical "type name" mapping metadata in terms of the correlated JavaTypeDescriptor/SqlTypeDescriptor combo. For example Hibernate would always interpret numerous variations on the old basic type registry's key for "String" to mean the JavaTypeDescriptor(String)/SqlTypeDescriptor(VARCHAR). So we do that still, but in this new composition way.
For the cases where users specified Type class names, e.g. {{org.hibernate.type.StringType}}, (by class name) we could handle cases where the class names were our legacy names by using the new composition.
For other . you can specify the Type class name... we'd have to decide
** I wonder too if we should keep {{org.hibernate.type.BasicType}} as well somehow as it is by far the most used and implemented of the Types we are removing (having it subclass the new {{org.hibernate.type.spi.BasicType}} interface and delegating method calls as needed via default impls).
The question above wrt continuing
I question whether we should continue to support
The least obvious is how to allow metadata to indicate the JavaTypeDescriptor to use. One option is to Another option specifically g
|
