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 <st...@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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
