{code}
@Entity
class SomeEntity {
@Basic
String someStringValue;
}
{code}
So we know that `someStringValue` is a basic type and that its Java type is String. But we are still left to guess how to handle this in terms of the underlying database column. Atm we make an assumption based on the fact that the field type is a String, we use that to resolve that to Hibernate's {{StringType}} which maps a String to a VARCHAR.
There are already recognized "hints" intended to help alter the relational understanding. E.g. {{@Lob}}, {{@Nationalized}}, etc. What is being proposed here are some additions to these. Specifically I can see:
# {{@JdbcTypeCode}} - i.e. {{@JdbcTypeCode(Types#LONGNVARCHAR) @Basic String someStringValue;}}
# {{@MutabilityPlan}}
# {{@Comparator}}
# some annotation to specify an "equals and hashCode" stratgey
# some annotation to specify a wrap/unwrap strategy
The last 4 really just describe the components of a JavaTypeDescriptor, so we'd only need those if a JavaTypeDescriptor is not known or if the user wants deviations from the normal semantics .
These values would also get picked up by AttributeConverter support for it to be able to better understand the various "types" (the 2 JavaTypeDescriptors and the SqlTypeDescriptor) involved in its conversion |
|
