[hibernate-dev] Another @Access quandry

[Steve Ebersole]

I really like the general approach you did in metamodel.  In fact, even
though I heavily refactored most of that package, the way annotated members
are found is largely unchanged.

But specifically, take Sanne's example.  Access(PROPERTY) for the class.
 Then for one attribute they want field *access* (runtime).  How would you
see that?  Like I said initially, I think there are 2 potentially valid
ways to support this.

First,

@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
    @Id
    @GeneratedValue
    @Access(AccessType.FIELD)
    private long id;
    ...

    public long getId() {
        return id;
    }
    ...
}

This approach gives credence to the passage I have been quoting here: "It
is not permitted to specify a field as Access(PROPERTY) or a property as
Access(FIELD)".


Second,

@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
    private long id;
    ...

    @Id
    @GeneratedValue
    @Access(AccessType.FIELD)
    public long getId() {
        return id;
    }
    ...
}

I prefer the first one.



On Wed, Mar 26, 2014 at 2:36 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:

>
> On 26 Jan 2014, at 15:56, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > But the original test represents a quite naturally looking example and
> > it's hard to justify why that should be considered illegal;
>
> Because it is against the rules for the placement of @Access.
> At least in my interpretation of the spec.
>
> > Ignoring any annotation leads to waste of time and debugging
> > frustration, so rather than silently discarding a mis-positioned
> > annotation I'd prefer a fail-fast approach;
>
> True. There are several bug reports  due to the fact that we ignore
> mapping information.
> However, we never have taken all annotations into consideration. The
> approach has always
> been to first determine where to look for annotations (per default based
> on the placement of
> the @Id annotation) and then only consider annotations placed according to
> the discovered strategy.
>
> I would assume there were two reasons for ignoring "wrongly" placed
> annotations:
> - annotation processing time and the attempt to avoid accessing all fields
> and getters via reflection
> - a considerable extra effort in coding to do proper processing and error
> handling
>
> Personally I could imagine an option where we determine an default
> annotation placement and
> throw an exception if any mapping annotation is wrongly placed. If the
> option is disabled
> we ignore (maybe log) the annotation.
>
> > that said I think just
> > applying them all - as long as there are no obvious conflicting
> > annotations - would be even more user friendly and doesn't seem to
> > violate any specific wording of the spec.
>
> -1
>
> --Hardy