[hibernate-dev] Another @Access quandry

[Steve Ebersole]

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 at hibernate.org>wrote:

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