Re: [hibernate-dev] Another @Access quandry
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.