[hibernate-dev] Another @Access quandry

[Steve Ebersole]

Here is what I am trying to decide between in terms of support for this.
 Mainly this is a usability matter for me.  Part of usability is how easily
we can explain this so users can understand and use it.  To me there are 2
paths to high usability here...


== Consistency

The first path would be to be consistent in what "access type" means and
its implications.  For example, to me that would mean at the beginning of
this topical guide I can make the following statement truthfully, then to
me we have consistency:

<quote>
A persistent attribute is defined as either FIELD or PROPERTY access (in
strict JPA sense).  FIELD access means that:
1) A persistent attribute is identified by its Class field
2) The mapping annotations for the persistent attribute are located on the
Class field
3) At runtime we access the persistent attribute's value directly via the
field.

PROPERTY access means:
1) A persistent attribute is identified by its JavaBeans-style getter and
setter on a Class
2) The mapping annotations for the persistent attribute are located on the
Class getter method
3) At runtime we access the persistent attribute's value via the
getter/setter methods.
</quote>

>From there its just a matter of rules for "which" wins at the various
levels (hierarchy, class, attribute).


== ItJustWorks

This is more the proposal of Sanne iiuc.  Here, "where to look for mapping
annotations" is irrelevant; the idea being that we'd look both on the field
and the getter and "merge" the metadata.  Another implication here is that
@Access explicitly identifies how they are accessed at runtime (and I'd
assume this in turn drives the recognition of what are the persistent
attributes).

There is definitely a beauty here in that the rules are again pretty simple
to explain and understand.  The thing that worries me is the part about
"merging" the metadata.  Sanne gave some simple examples of where this
would possibly be difficult.  But there are others, some even more
difficult.  One that immediately jumps to my mind is "plural" annotations;
for example:

@ManyToOne
@JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} )
private Person person;

@ManyToOne
@JoinColumns( {@JoinColumn( .. ), @JoinColumn( .. ), ..} )
public getPerson() { return person; }

Is this 4 join-columns?  2?  Error?

I think at the very least we should be enforcing that the annotations
appear consistently (either all on field or all on getter) for a given
attribute *if* we were to go this route.




On Thu, Mar 27, 2014 at 9:50 AM, Steve Ebersole <steve at hibernate.org> wrote:

> 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.
>>
>
>