users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: _at_Convert precedence

From: Kevin Sutter <sutter_at_us.ibm.com>
Date: Fri, 30 Aug 2013 12:58:26 -0500

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.
> >>>> > >>>
> >>>> >
> >>>
> >>
>