On 27 Jan 2014, at 19:36, Steve Ebersole <steve(a)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.