[hibernate-dev] Another @Access quandry

[Steve Ebersole]

Here is how I phrase this atm in the topical guide:


[NOTE]
====
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 at hibernate.org> wrote:

>
>
>
> On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero <sanne at 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.
>