After looking through this some more, I think what you say could almost
work. But:
1) Still need a way to determine the declarer of a property rather than
just blindly accepting XProperty.getAnnotation(Convert.class). This is
needed for the Super/Sub MappedSuperclass/Entity case in my initial
email to properly interpret Convert precedence. Is the best option
here a change to hibernate-commons-annotations, and if so what change
specifically? Adding `XClass XProperty#getDeclarer()`?
2) As you say, AbstractPropertyHolder does account for
subclass/superclass precedence during its init. But I am not sure how
to hook in normalized path-based handling here.
2.a) It seems like there are times when
org.hibernate.cfg.AbstractPropertyHolder#parent would be useful for
what I need to do. But there appears to be times when this is null.
For entity mappings (ClassPropertyHolder) thats fine. But for the
others, that would be problematic. Going back to the
Person#homeAddress example, I'd really need the ComponentPropertyHolder
for Person#homeAddress to register the converts with
ClassPropertyHolder<Person> under the "homeAddress" base key
("homeAddress.city" for example). Is there a time here where
AbstractPropertyHolder#parent would be null for
ComponentPropertyHolder/CollectionPropertyHolder?
2.b) Is this AbstractPropertyHolder#parent the best way you see to
handle path-based converts? Or do you see a better option?
On Fri 30 Aug 2013 10:52:40 AM CDT, Emmanuel Bernard wrote:
> On Fri 2013-08-30 10:13, Steve Ebersole wrote:
>> Hit send too early...
>>
>>
>> On 08/30/2013 09:55 AM, Steve Ebersole wrote:
>>> 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.
>>
>> This ^^ is difficult to achieve in the "annotation reader".
>
> That's what is done for Attribute Override in AbstractPropertyHolder.
> You can control the order in which sub/spuer class a processed it and
> control how composition from a property holder to its parent is done.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
