On 27 Jan 2014, at 19:36, Steve Ebersole <st...@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.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
