Reference HHH-9615[1].
The specific request here is to support @Lob together with an
AttributeConverter. But other combinations apply as well. So I want to
address the more generic case, but let's talk in terms of this specific
case.
Ultimately the problem is in SimpleValueBinder and the fact that it keeps
just one representation of the "determined Type" (`explicitType`) and that
it furthermore treats that value as if it were explicitly requested. When
it is determining the Type to use and it sees @Lob, @Natioanlized, etc it
assumes that that implicitly defines the Type to use, but then treats that
determination as if it were explicit.
Late we have a check to make sure that the user did not mix applying an
AttributeConverter and an (really) explicit Type definition on an
attribute, because that would be a unresolvable situation.
Really, instead I think this should work quite differently. To me, I would
not say that @Lob equates to an explicit Type request. Instead I would say
that it is a hint as to the Type, and actually even more limited I would
say it is a hint as to just the JDBC type. Really @Lob has no bearing on
the Java model type.
So what I'd propose instead (keeping changes as minimal as possible until
we rewrite the annotation binding code) would be to defer this decision for
@Lob into SimpleValue itself. I think the least disruptive way would be a
method on SimpleValue similar in intent to SimpleValue#makeNationalized.
So add a SimpleValue#makeLob that we'd call from SimpleValueBinder when
@Lob was present. We would then incorporate handling LOB interpretation
into SimpleValue#setTypeUsingReflection and
SimpleValue#buildAttributeConverterTypeAdapter.
Does this sound reasonable to everyone? Emmanuel, you wrote and designed
SimpleValueBinder; does that make sense from the perspective of the overall
design/intent of SimpleValueBinder?
[1]
https://hibernate.atlassian.net/browse/HHH-9615