Earlier determination of nature of @Type, etc

[sebersole]

For background, this is growing from a discussion about the best way to handle CompositeUserType in 6. For the background discussions see -

• CompositeUserType #3960
• https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/CompositeUserType

Currently, Hibernate's @Type and `@TypeDef`` annotations are String-based in terms of resolving the user or built-in type to use. When binding these during bootstrap (as currently handled), this causes difficulty since they can define a type of either basic or composite nature. We simply do not know early enough which nature is intended. E.g.

@Entity
class TheEntity {
  ...
  @Type( type = "SomethingType" )
  Something something;
}

As we start binding this entity, we have no idea whether this attribute is a basic type or a composite. Naively speaking, we could just "peek" at the String and try to decide what the nature is early but that actually won't work because of @TypeDef.

I was thinking this could be as simple as introducing a single new annotation:

@interface Composition {
    Class<? extends CompositeUserType> impl() ;
}

and then:

@Entity
class TheEntity {
  ...
  @Composition( impl = SomethingType.class )
  Something something;
}

Or, if we see no other config options here ever:

@interface Composition {
    Class<? extends CompositeUserType> value() ;
}

and :

@Entity
class TheEntity {
  ...
  @Composition( SomethingType.class )
  Something something;
}

Of course, we'd need variations of this for Map keys, etc...

I also think that this should not work with @TypeDef, though maybe y'all have a use case in mind where that might be useful. IMO, that should be a whole new annotation as well but then we'd either need (1) to allow @Composition (and @MapKeyComposition, ect) to name a composition-type-def or a whole new set of type-def based @Composition varants. Personally, I'd just avoid this mess.

A related discussion then is whether to give basic user type annotations a similar treatment. My main concern there is the distinction between a user type versus a built-in type. If we decide we want to go this route, one option would be to keep @Type, @MapKeyType and @TypeDef as they are today (limiting that they only apply to basic types) and add a new annotation (with map-key variant):

@interface UserType {
  Class<? extends UserType> value();
}

[beikov]

I think we can get rid of these annotations. See my comment for details #3960 (reply in thread)

[sebersole]

I'm not following what you are suggesting here wrt basic-types. Are you suggesting we get rid of custom types altogether?

[beikov]

I'm suggesting that we can get rid of the annotation and rely on a converter in case we pull it of like I suggested in my other comment.

[sebersole]

I'm not a fan of AttributeConverter for composites at all. Unless you mean something other than AttributeConverter when you say "converter"?

[beikov]

I mean the AttributeConverter, yes. Well, if we have the intermediary type, then it would be quite natural to do it this way IMO. Also, since we have an answer to configure mutability etc. for the converter, we could AFAICT model everything we need.