[hibernate-dev] Another @Access quandry

[Hardy Ferentschik]

On 27 Jan 2014, at 19:36, Steve Ebersole <steve at hibernate.org> wrote:

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

My vote goes to consistency.


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

Right, that would be the minimum requirement.