[hibernate-dev] hiberate-commons-annotations and locating annotations

[Steve Ebersole]

Its not that easy.  This is not as simple as AttributeOverride.  The 
rules here are much more complex (or convoluted, depending on your 
perspective).  An AttributeOverride always overrides.  The is just not 
the case here with converters.  Plus how AttributeOverride works does 
not need to vary from one use case to another (basics, composites, 
plurals).


On Fri 30 Aug 2013 07:47:36 AM CDT, Emmanuel Bernard wrote:
> On Fri 2013-08-30  6:27, Steve Ebersole wrote:
>>
>> On Fri 30 Aug 2013 06:05:37 AM CDT, Emmanuel Bernard wrote:
>>>>
>>>>
>>>> 2) The 'declaringClassName' passed in to SimpleValueBinder#setType
>>>> is Sub. So maybe we can leverage that. But
>>>> org.hibernate.cfg.annotations.PropertyBinder#makePropertyAndValue
>>>> (the main caller of this method) has explicit handle for null-ness
>>>> so that makes me nervous.
>>>>
>>>> Given the differing rules for resolving converter to use for basic
>>>> types, collections and composites and the fact that these
>>>> distinctions are already handled in the PropertyHolder hierarchy, I
>>>> think it would be better to handle those distinctions there. Either
>>>> adding a separate method to inject the converter to use (making sure
>>>> it is called before setType, ugh) or changing the signature of
>>>> setType to accept the converter to use.
>>>> PropertyBinder#makePropertyAndValue would then use
>>>> PropertyHolder#resolveAttributeConverter to pass what it needs to
>>>> pass.
>>>>
>>>> WDYT?
>>>
>>>
>>> Yes that makes sense to consolidate this logic in PropertyHolder. But I
>>> have to admit I failed to find an elegant algorithm and data structure
>>> to resolve the convert use cases you have described. All involved some
>>> back reading of annotations etc :(
>>
>> Depends what you mean "back-reading".  I planned on sifting through
>> the annotations as "resolve" is called.
>>
>>>
>>> BTW is it possible to have the illegal case by mean of mixing XML and
>>> annotation. ie you have the @Convert on the property and the disable
>>> facility at the class level in XML. Does the same rule apply?
>>> Because for sure the XML and the annotation are treated equally by
>>> commons annotation.
>> <quote>
>> The convert subelement is additive to any Convert or Converts
>> annotations on the entity. It
>> overrides any Convert annotation for the same attribute name. If a
>> convert subelement is present,
>> and attributes or subelements of that convert subelement are not
>> explicitly specified, their default
>> values are applied
>> </quote>
>>
>> My reading of that on your use-case is that we really should apply
>> the XML-defined converter.  But hiberate-commons-annotations simply
>> does not give us the information needed to be able to do that
>> properly.
>
> You can do that, you would code the logic in JPAOverriddenAnnotationReader in ORM Core.
> Check getAttributeOverrides / mergeAttributeOverrides as an example of
> how to read Java annotation, the XML "annotations" and merge the two as
> you please.