>
> AccessType in JPA means both but is also much more limited than our
>
PropertyAccessor approach. If your plan is to separate them in the
> metamodel, then +1 and if propertyAccessor is not set, fall back to
> JPA's default behavior.
>
What I mean is that currently we utterly have no internal support for
recognizing:
@Access(FIELD)
@AttributeAccessor("property")
...
private String someAttribute;
which is perfectly valid (aka, look to the field for annotations, but at
runtime access getter/setters). There are really 2 questions here in
Hibernate terminology. As you say, JPA simply condenses that to one and
limits it.
The idea of AccessType (where to look for annotations) is what it is;
Hibernate's PropertyAccessor contract (AttributeAccessor annotation) has no
bearing on that. Given a missing AttributeAccessor annotation, we will
default the PropertyAccessor based on the attribute's AccessType.
> I don't know where it is exactly where you need the distinction, but if
you do,
> I also think they should be kept separated. Also having distinct concepts
for this maybe
> makes concepts also a bit clearer.
Right, aside from cleanliness/correctness, one place at least where I have
seen it be problematic is in building the JPA metamodel. One thing we are
supposed to return is the "java member" for the attribute
(javax.persistence.metamodel.Attribute#getJavaMember). I guess it is
somewhat arguable given that the spec does not describe what exactly is
expected here. Which is not surprising since the spec condenses both
concepts together. But I'd think that the more correct return there is the
"annotated member". Which is exactly opposite of what we do today when
these conflict.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
