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