Re: [hibernate-dev] Another @Access quandry
Since there seems to be no unanimous consensus, the majority consensus
seems to be to for that (1) approach. So that's going to be my working
principle here for now.
Another thought...
Again to me this all comes down to 1 concept in JPA being used to represent
3 different things. That's never a good situation. So maybe internally we
start representing all 3 distinctly. As we model and understand things
separately it makes it easier to handle each separately. For example, we
might have:
1) A strategy for recognizing the persistent attributes for a class
2) A (swappable, maybe) strategy for collecting the mapping annotations
related to a persistent attribute
3) A strategy for accessing the attribute at runtime (our PropertyAccessor
stuff).
(2) would be the thing that would allow for what Sanne is asking about. By
default we'd not support that, but through a switch or pluggable strategy
would could.
Agains, there are 3 parts to this discussion. Previously we modeled 1! I
have just changed this recently to model 2. Maybe we actually model all 3?
On Thu, Mar 27, 2014 at 2:01 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
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.