[hibernate-dev] AttributeConverter and type "hints"

[Steve Ebersole]

So here is what I ended up doing concretely and anyone can chime in if this
sounds off..

1) In SimpleValueBinder I added a new field isLob to match isNationalized
2) In SimpleValueBinder#setType, when we see @Lob I:
2.a) set isLob to true
2.b) set SimpleValueBinder#defaultType, rather than
SimpleValueBinder#explicitType
3) In SimpleValueBinder#make, if SimpleValueBinder#isLob is true I pass
that along to SimpleValue

Now, when SimpleValue#setTypeUsingReflection is called we have the
information available to know that the db value should be a LOB just like
we already knew that it should be nationalized.

This change caused no regressions.

On Sat, Oct 3, 2015 at 9:22 AM Steve Ebersole <steve at hibernate.org> wrote:

> 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
>