Here is how I phrase this atm in the topical guide:
It is important to understand that generally speaking the phrase "access
type" refers to a number of concepts:
* Determining which fields/methods constitute a persistent attribute.
* Indicating where to look for mapping annotations.
* How the attribute (its value) is accessed at runtime
For the most part, Hibernate treats all 3 as being the same. There are
some caveats here, which we will cover
as we go along.
On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
> I don't argue with that, but the context of my example was "assuming
> my team has the convention of always putting mappings on properties",
> so in such a case I'd want to use the second.
Like I said, I could really live with either interpretation. The sole
reason I lean towards #1 is the idea of consistency. If you start allowing
@Access(FIELD) on getters all of a sudden @Access(FIELD) has a different
semantic depending on where you find it (class versus attribute).
As I am writing the topical guide, I am realizing there are really 3
questions involved here:
1) How do I determine what is (versus is not) a "persistent attribute"?
2) Where do I look for mapping annotations for each persistent attribute?
3) How do I access persistent attribute values at runtime?
This is really where we all (and not just us...) have varying opinions.
Like you think (1) and (2) should be handled distinctly, whereas the rest
of us (iiuc) think that (1) and (2) should be determined via the same logic.
Further, you see the (1)/(2) combo as distinct from (3). To you
@Access(FIELD) on the getter is fine because of this; there @Access(FIELD)
is merely identifying the style of runtime access.
Not saying either is right or wrong. I just think it helps to better
understand where/why we all agree/disagree. Which ultimately gives us
better understanding in these discussions.
> I really have no strong feeling against how you all think it should be
> or any spec wording, my only concern is what happens when someone does
> have a different interpretation or opinion. AFAIK today these are
> ignored: would be nice to eventually be able to strictly validate (for
> whatever decison you might take).
> I think that's important to be taken into consideration while you work
> on how Jandex reads things: to be able to provide strict validation,
> you will need to be able to read annotations from both positions.
For sure. This is one of the things metamodel is striving to do better
than before in regards to recognizing and warning about misplaced
annotations that will be ignored.