To be honest, in these cases where more than one conversion (@Convert)
is specified at the "same level", I think it makes more sense to say
that the behavior is undefined rather than attempt to mandate that it is
specifically an error.
Related question:
<converter/> as allowed in orm.xml... Is that supposed to define a
converter available to any and all classes? Or just the classes defined
within the orm.xml?
Also, in Hibernate I allowed converters to be listed in persistence.xml
under <class/> entries. But in reviewing the spec, I do not see that
mentioned anywhere. Did I just make that up?
On 08/30/2013 12:58 PM, Kevin Sutter wrote:
> Hi Steve,
> Sounds like another thing to add to Linda's errata clarification...
> :-) Nice catch.
>
> -- Kevin
>
>
> Steve Ebersole <steve.ebersole_at_redhat.com> wrote on 08/30/2013
> 10:03:13 AM:
>
> > From: Steve Ebersole <steve.ebersole_at_redhat.com>
> > To: jsr338-experts_at_jpa-spec.java.net,
> > Cc: Linda DeMichiel <linda.demichiel_at_oracle.com>
> > Date: 08/30/2013 10:04 AM
> > Subject: [jsr338-experts] Re: @Convert precedence
> >
> > So what about XML overrides? Here we have the same concern. Consider:
> >
> > @Entity
> > public class Person {
> > ...
> > @Convert( converter=FirstNameConverter.class )
> > public String firstName;
> > }
> >
> >
> > In terms of XML, the XSD gives users a choice:
> >
> > <entity class="Person">
> > <convert attributeName="firstName" disableConversion="true"/>
> > </entity>
> >
> > or:
> >
> > <entity class="Person">
> > <attributes>
> > <basic name="firstName">
> > <convert disableConversion="true"/>
> > </basic>
> > </attributes>
> > </entity>
> >
> >
> > So is the first form treated as an error? Like we do if they had said:
> >
> > @Entity
> > @Convert( attributeName="firstName", disableConversion=true )
> > class Person{
> > ...
> > @Convert( converter=FirstNameConverter.class )
> > String firstName;
> > }
> >
> >
> > In regards to this form (child of <entity/>, section 12.2.3.16), the
> > spec does specifically say:
> >
> > <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...
> > </quote>
> >
> > But this was written before the situations being discussed here were
> > considered.
> >
> >
> > On Thu 22 Aug 2013 01:47:56 PM CDT, Linda DeMichiel wrote:
> > >
> > > I agree with what has been said in this discussion so far. I will
> > > flag this
> > > as an errata to be clarified in the next draft of the spec.
> > >
> > > -Linda
> > >
> > >
> > > On 8/22/2013 10:03 AM, gordon yorke wrote:
> > >>
> > >> Example 1 should be an error case because the @Convert is being
> > >> specified at effectively the same level.
> > >> --Gordon
> > >>
> > >> On 22/08/2013 1:54 PM, Steve Ebersole wrote:
> > >>>
> > >>> Yeah, I totally agree that these should override in the embedded
> > >>> case. That makes the most sense. To me its a matter
> > >>> of the more specific context. The problem for me is that, in my (1)
> > >>> the local Convert is actually the more specific
> > >>> context.
> > >>>
> > >>> On Thu 22 Aug 2013 11:42:15 AM CDT, Kevin Sutter wrote:
> > >>>>
> > >>>> Hi,
> > >>>> In section 11.1.10, there is this statement:
> > >>>>
> > >>>> "The Convert annotation may be applied to an entity class that
> extends
> > >>>> a mapped superclass to specify
> > >>>> or override a conversion mapping for an inherited basic or embedded
> > >>>> attribute."
> > >>>>
> > >>>> It's close to clarifying your (2) example, except you are not
> using a
> > >>>> mapped superclass. But, it does indicate that the @Convert at the
> > >>>> Entity level overrides the embedded attribute...
> > >>>>
> > >>>>
> >
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> > >>>>
> > >>>>
> > >>>>
> > >>>> Kevin Sutter
> > >>>>
> > >>>>
> > >>>>
> > >>>> gordon yorke <gordon.yorke_at_oracle.com> wrote on 08/22/2013 09:53:14
> > >>>> AM:
> > >>>>
> > >>>> > From: gordon yorke <gordon.yorke_at_oracle.com>
> > >>>> > To: jsr338-experts_at_jpa-spec.java.net,
> > >>>> > Date: 08/22/2013 09:55 AM
> > >>>> > Subject: [jsr338-experts] Re: @Convert precedence
> > >>>> >
> > >>>> > I do not think it applies in this case either, I was just
> > >>>> pointing out
> > >>>> > the only place in the specification that mentions configuring a
> > >>>> > duplicate @Convert on the same attribute. The only other
> > >>>> reference to
> > >>>> > multiple converters for the same attribute is in the
> > >>>> > @Converter(autoApply) flag and in that case an @Convert is
> > >>>> required to
> > >>>> > specify which converter is used.
> > >>>> >
> > >>>> > --Gordon
> > >>>> >
> > >>>> > On 22/08/2013 11:45 AM, Steve Ebersole wrote:
> > >>>> > > Ah, I found it... 11.1.11 Converts Annotation
> > >>>> > >
> > >>>> > > I am not sure that is really talking about the situation I
> > >>>> described,
> > >>>> > > or maybe it is just misplaced. My examples are not using
> > >>>> @Converts.
> > >>>> > >
> > >>>> > >
> > >>>> > > On Thu 22 Aug 2013 09:43:33 AM CDT, Steve Ebersole wrote:
> > >>>> > >> Thanks for the reply Gordon. Where did you find that in the
> > >>>> spec? I
> > >>>> > >> did a search on that quote and found no matches.
> > >>>> > >>
> > >>>> > >> On Thu 22 Aug 2013 09:38:54 AM CDT, gordon yorke wrote:
> > >>>> > >>> Hello Steve,
> > >>>> > >>> The specification says in reference to @Converts that
> "Multiple
> > >>>> > >>> converters must not be applied to the same basic attribute."
> > >>>> but in
> > >>>> > >>> this case it makes sense to have the convert on the Embedded
> > >>>> attribute
> > >>>> > >>> override the convert within the Embeddable.
> > >>>> > >>> --Gordon
> > >>>> > >>>
> > >>>> > >>> On 22/08/2013 11:09 AM, Steve Ebersole wrote:
> > >>>> > >>>> I could not find mention of this in the spec so wanted to
> > >>>> start a
> > >>>> > >>>> discussion within the group. The concern is what to do when
> > >>>> multiple
> > >>>> > >>>> @Convert definitions can apply to a given attribute. If the
> > >>>> spec
> > >>>> > >>>> does cover this, I apologize; if so, could someone point out
> > >>>> the
> > >>>> > >>>> section?
> > >>>> > >>>>
> > >>>> > >>>>
> > >>>> > >>>> 2 examples:
> > >>>> > >>>>
> > >>>> > >>>> 1) non-path
> > >>>> > >>>>
> > >>>> > >>>> @Entity
> > >>>> > >>>> @Convert( attributeName="firstName",
> > >>>> converter=FNameConverter.class )
> > >>>> > >>>> class Person{
> > >>>> > >>>> ...
> > >>>> > >>>> @Convert( converter=FirstNameConverter.class )
> > >>>> > >>>> String firstName;
> > >>>> > >>>> }
> > >>>> > >>>>
> > >>>> > >>>>
> > >>>> > >>>> 2) path
> > >>>> > >>>>
> > >>>> > >>>> @Entity
> > >>>> > >>>> @Convert( attributeName="homeAddress.city",
> > >>>> > >>>> converter=HomeAddressCityConverter.class )
> > >>>> > >>>> class Person {
> > >>>> > >>>> ...
> > >>>> > >>>> @Embedded
> > >>>> > >>>> Address homeAddress;
> > >>>> > >>>> }
> > >>>> > >>>>
> > >>>> > >>>> @Embeddable
> > >>>> > >>>> class Address {
> > >>>> > >>>> ...
> > >>>> > >>>> @Convert( converter=CityConverter.class )
> > >>>> > >>>> String city;
> > >>>> > >>>> }
> > >>>> > >>>>
> > >>>> > >>>>
> > >>>> > >>>> In (2) I think it is clearly better to apply
> > >>>> > >>>> HomeAddressCityConverter. But in (1) I think it is less
> > >>>> clear cut;
> > >>>> > >>>> there, personally, I'd think FirstNameConverter would be
> > >>>> applied.
> > >>>> > >>>> But not sure it makes sense to have different precedence
> rules.
> > >>>> > >>>
> > >>>> >
> > >>>
> > >>
> >