UserType

[sebersole]

UserType

UserType will have to change. Users will have to change their impls. That's not avoidable.

They will need to change to handle the overall move from reading by name to reading by position from the JDBC ResultSet. Also, they will need to change to account for the fact that BasicTypes are now limited to a single JDBC type.

Given that, we have some flexibility to improve the contract. As minimally as possible, ofc.

In what cases do we intend UserType to be used? In cases where there is a "conversion"? In cases describing a non-baseline JavaTypeDescriptor? This helps determine what we need from UserType. We have @JavaType, @JavaTypeRegistration, @JdbcType, @JdbcTypeCode, @JdbcTypeRegistration, @Convert, etc. Why UserType instead of a combination of those? One argument for keeping UserType is for users who would rather bundle all of that processing into a single thing to register.

// NOTE: mock-up
@UserTypeRegistration( impl = BitSetUserType.class )

compared to

@JavaTypeRegistration( javaType = BitSet.class, descriptorClass = BitSetJavaType.class )
@Converter( autoApply = true )
class BitSetConverter implements AttributeConverter<BitSet,String> {
    ...
}

JavaTypeDescriptor

UserTypes mapping Java types not known to the JavaTypeDescriptorRegistry cause problems in numerous cases.

A simple solution would be to auto-register a JavaTypeDescriptor wrapping the UserType for the mapped Java type. UserType has all of the information we need to implement JavaTypeDescriptor, including MutabilityPlan. However, this causes problems when multiple UserTypes get registered for the same Java type...

Maybe we restrict one UserType per Java type? Otherwise we will need to have UserType provide us the JavaTypeDescriptor to use, not just UserType#returnedClass

Conversion

UserTypes also sometimes (usually?) implement some form of conversion. When is having UserType better for that?

[beikov]

For the sake of backwards compatibility, keeping UserType but deprecating it is probably a nice middle way like we discussed today. I agree though that most of the time, it's probably enough to model this as attribute converters or java type descriptors. IMO, in the meantime we should auto-register java type descriptors wrapping user types like you suggested. The first one wins, in case multiple are available.

[gavinking]

Do you think we can get rid of EnhancedUserType, LoggableUserType, and perhaps even UserVersionType while we're at it?

[gavinking]

On the broader question, I would be inclined to retain UserType. It's still probably the quickest way to handle a certain class of usecases, even if it does overlap other facilities.

[sebersole]

This was my thought as well.

[yrodiere]

One use case for UserType that I know of is to define how to map business "wrapper" types. For example SomeBusinessCode contains only a String and should always be mapped as the text SQL type (on postgresql). This can be achieved with a (basic) user type.

Attribute converters only get you halfway there, since you don't get to define the SQL type, only the java type.

I suppose one could define the default SQL type for String as text, but what if you only want to use that type for SomeBusinessCode?

[beikov]

Indeed, in such a case one would have to add e.g. @JdbcTypeCode to the use-sites. Maybe we could allow putting this annotation on converters as well for defaults?

[sebersole]

Indeed, in such a case one would have to add e.g. @JdbcTypeCode to the use-sites. Maybe we could allow putting this annotation on converters as well for defaults?

We actually have started down this path already for other things and I think its a great idea. E.g. you can apply @Immutable on converters and types.