Re: [hibernate-dev] Another @Access quandry
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(a)hibernate.org>wrote:
On 26 Jan 2014, at 15:56, Sanne Grinovero <sanne(a)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