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

[Steve Ebersole]

Also, unless we have some normalization rules, my point was that we 
literally cannot do this today in annotations.

Essentially the bug-a-boo is composites (and maybe collections as 
composite via allowance of "map.", etc).  We'd essentially have to 
normalize all paths for converters to be the composite form relative to 
the "root" composite parent.  In other words, given the 
"Person.homeAddress.country" example (home address being embedded of 
type Address), we'd have to normalize all path references for converters 
to be "homeAddress.country" and kept/managed on Person. The trouble is 
that this makes the order in which we process these levels very 
important, and I am just not sure I trust binders as they are to enforce 
that ordering.


On 08/30/2013 09:06 AM, Emmanuel Bernard wrote:
> Yes I get that but JPAOverriddenAnnotationReader is only about reading
> the XML and converting it into annotations.
>
> I understand that implementing the rules based on the annotations is
> more complex than annotation override.
>
> On Fri 2013-08-30  8:44, Steve Ebersole wrote:
>> 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.