12:13 a.m.
From the test
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
we have the following:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
private long id;
...
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
...
}
The test asserts that this is a valid mapping. Granted that the spec is
very unclear here, so I might be missing something. The pertinent spec
section here states:
*<quote>When Access(PROPERTY) is applied to an entity class, mapped
superclass, or embeddableclass, mapping annotations may be placed on the
properties of that class, and the persistenceprovider runtime accesses
persistent state via the properties defined by that class. All proper-ties
that are not annotated with the Transient annotation are persistent.
WhenAccess(PROPERTY) is applied to such a class, it is possible to
selectively designate indi-vidual attributes within the class for instance
variable access. To specify a persistent instancevariable for access by the
persistence provider runtime, that instance variable must be desig-nated
Access(FIELD).</quote>*
I can see a few different ways to read that:
1) @Access can be placed on the attribute to define both where to look for
mapping annotations and the runtime access strategy for a given attribute.
Here, we'd do:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Id
@GeneratedValue
@Access(AccessType.FIELD)
private long id;
...
public long getId() {
return id;
}
...
}
2) @Access can be placed on the attribute to define the runtime access
strategy for a given attribute, but the class/hierarchy AccessType controls
where to look for mapping annotations. This would lead to:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Access(AccessType.FIELD)
private long id;
...
@Id
@GeneratedValue
public long getId() {
return id;
}
...
}
The test seems to illustrate that our legacy code made yet a 3rd reading of
this passage such that @Access is still considered a "mapping annotation"
even though that seems to directly contradict "To specify a persistent
instance
variable for access by the persistence provider runtime, that instance
variable must be desig-
nated Access(FIELD)."
Is there some other passage I am missing that bears on what to do here?
How do y'all feel about that passage and its implications on this test
mapping?
7:12 a.m.
As a user I would not expect the @Access annotation to be treated as a
special case by the framework in terms of when an annotation is
ignored, as for example that I can put this on either properties or
fields, and it would not be ignored, while other annotations could be
ignored depending on the position.
Also I highly doubt that there is a practical use case to "comment" a
mapping annotation by moving it to the wrong position (say I move a
@GeneratedValue from a field to a property when using FIELD access):
that would be extremely confusing to maintain.
The spec's wording states "When Access(PROPERTY) is applied to an
[...] mapping annotations **may** be placed on .."
I'd stress that it doesn' t say "must" but "may", and also
doesn't
seem to strictly ban the opposite.
As a user if I put a mapping annotation anywhere I expect it to be
respected, so I would expect the framework to work on the union of the
possible positions, and probably even to throw an exception on
conflicting options. The @Access property would then only be used to
state which access strategy should be used (and a nice effect is tha
the name becomes particularly self-explanatory too).
Also there are many types of possible contradictions in the mapping options:
public class Course {
@Id @GeneratedValue(strategy=TABLE)
private long id;
...
@Id @GeneratedValue(strategy=SEQUENCE)
public long getId() {
return id;
}
Or you could have a stronger conflict which isn't solvable via
AccesType "rules" either:
public class Course {
@Id @GeneratedValue(strategy=TABLE)
@Access(AccessType.FIELD)
private long id;
...
@Id @GeneratedValue(strategy=SEQUENCE)
@Access(AccessType.PROPERTY)
public long getId() {
return id;
}
This last example is the reason why I think you should always
consistently look at both to collect mapping options, and possibly
throw runtime exceptions.
Sanne
On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org> wrote:
>From the test
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
we have the following:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
private long id;
...
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
...
}
The test asserts that this is a valid mapping. Granted that the spec is
very unclear here, so I might be missing something. The pertinent spec
section here states:
*<quote>When Access(PROPERTY) is applied to an entity class, mapped
superclass, or embeddableclass, mapping annotations may be placed on the
properties of that class, and the persistenceprovider runtime accesses
persistent state via the properties defined by that class. All proper-ties
that are not annotated with the Transient annotation are persistent.
WhenAccess(PROPERTY) is applied to such a class, it is possible to
selectively designate indi-vidual attributes within the class for instance
variable access. To specify a persistent instancevariable for access by the
persistence provider runtime, that instance variable must be desig-nated
Access(FIELD).</quote>*
I can see a few different ways to read that:
1) @Access can be placed on the attribute to define both where to look for
mapping annotations and the runtime access strategy for a given attribute.
Here, we'd do:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Id
@GeneratedValue
@Access(AccessType.FIELD)
private long id;
...
public long getId() {
return id;
}
...
}
2) @Access can be placed on the attribute to define the runtime access
strategy for a given attribute, but the class/hierarchy AccessType controls
where to look for mapping annotations. This would lead to:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Access(AccessType.FIELD)
private long id;
...
@Id
@GeneratedValue
public long getId() {
return id;
}
...
}
The test seems to illustrate that our legacy code made yet a 3rd reading of
this passage such that @Access is still considered a "mapping annotation"
even though that seems to directly contradict "To specify a persistent
instance
variable for access by the persistence provider runtime, that instance
variable must be desig-
nated Access(FIELD)."
Is there some other passage I am missing that bears on what to do here?
How do y'all feel about that passage and its implications on this test
mapping?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:02 a.m.
My reading at the time and what I did find more intuitive is what the
test represents.
Entity level @AccessType expresses where the annotations should
be. Otherwise the position of @Id is used to find the access type to
consider annotation wise.
If for a few attributes I wish to use the alternative property access, I
can add @AccessType next to the other annotations but expressing that
the actual property value access is based on the alternative access.
That way, all annotations are in the same place.
On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
As a user I would not expect the @Access annotation to be treated as
a
special case by the framework in terms of when an annotation is
ignored, as for example that I can put this on either properties or
fields, and it would not be ignored, while other annotations could be
ignored depending on the position.
Also I highly doubt that there is a practical use case to "comment" a
mapping annotation by moving it to the wrong position (say I move a
@GeneratedValue from a field to a property when using FIELD access):
that would be extremely confusing to maintain.
The spec's wording states "When Access(PROPERTY) is applied to an
[...] mapping annotations **may** be placed on .."
I'd stress that it doesn' t say "must" but "may", and also
doesn't
seem to strictly ban the opposite.
As a user if I put a mapping annotation anywhere I expect it to be
respected, so I would expect the framework to work on the union of the
possible positions, and probably even to throw an exception on
conflicting options. The @Access property would then only be used to
state which access strategy should be used (and a nice effect is tha
the name becomes particularly self-explanatory too).
Also there are many types of possible contradictions in the mapping options:
public class Course {
@Id @GeneratedValue(strategy=TABLE)
private long id;
...
@Id @GeneratedValue(strategy=SEQUENCE)
public long getId() {
return id;
}
Or you could have a stronger conflict which isn't solvable via
AccesType "rules" either:
public class Course {
@Id @GeneratedValue(strategy=TABLE)
@Access(AccessType.FIELD)
private long id;
...
@Id @GeneratedValue(strategy=SEQUENCE)
@Access(AccessType.PROPERTY)
public long getId() {
return id;
}
This last example is the reason why I think you should always
consistently look at both to collect mapping options, and possibly
throw runtime exceptions.
Sanne
On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org> wrote:
> >From the test
>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> we have the following:
>
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> private long id;
> ...
>
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> public long getId() {
> return id;
> }
> ...
> }
>
> The test asserts that this is a valid mapping. Granted that the spec is
> very unclear here, so I might be missing something. The pertinent spec
> section here states:
>
>
>
>
>
>
>
>
>
>
> *<quote>When Access(PROPERTY) is applied to an entity class, mapped
> superclass, or embeddableclass, mapping annotations may be placed on the
> properties of that class, and the persistenceprovider runtime accesses
> persistent state via the properties defined by that class. All proper-ties
> that are not annotated with the Transient annotation are persistent.
> WhenAccess(PROPERTY) is applied to such a class, it is possible to
> selectively designate indi-vidual attributes within the class for instance
> variable access. To specify a persistent instancevariable for access by the
> persistence provider runtime, that instance variable must be desig-nated
> Access(FIELD).</quote>*
>
>
> I can see a few different ways to read that:
>
> 1) @Access can be placed on the attribute to define both where to look for
> mapping annotations and the runtime access strategy for a given attribute.
> Here, we'd do:
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> private long id;
> ...
>
> public long getId() {
> return id;
> }
> ...
> }
>
> 2) @Access can be placed on the attribute to define the runtime access
> strategy for a given attribute, but the class/hierarchy AccessType controls
> where to look for mapping annotations. This would lead to:
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> @Access(AccessType.FIELD)
> private long id;
> ...
>
> @Id
> @GeneratedValue
> public long getId() {
> return id;
> }
> ...
> }
>
> The test seems to illustrate that our legacy code made yet a 3rd reading of
> this passage such that @Access is still considered a "mapping annotation"
> even though that seems to directly contradict "To specify a persistent
> instance
> variable for access by the persistence provider runtime, that instance
> variable must be desig-
> nated Access(FIELD)."
>
>
> Is there some other passage I am missing that bears on what to do here?
> How do y'all feel about that passage and its implications on this test
> mapping?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:53 a.m.
I think you are misreading the use of the term "may" there to mean that
annotations could be placed on the field or on the getter. I read it to
mean that that "may" be placed on the getter, or not (remember many
attributes do not require annotations be present).
I personally think it makes no sense to mix placement of annotations for a
given attribute. When you say "The @Access property would then only be
used to state which access strategy should be used (and a nice effect is
tha the name becomes particularly self-explanatory too)", I think you are
making an assumption about the meaning of the terms "access" and "access
type" that the spec simply does not consistently back. In fact the very
next sentence after what I quoted says (still discussing class-level
Access(PROPERTY)) : "The behavior is undefined if mapping annotations are
placed on any instance variables defined by the class for which
Access(FIELD) is not specified". Granted the spec says the behavior is
undefined, so we are free to support that if we want. However, it is
clearly not the intended behavior.
As I have brought up on the list a few times now recently, the notion of
"access" is really 2-fold in terms of identifying:
1) where to look for annotations at binding time
2) how to extract value from and inject value into the attribute at runtime
It is just so odd in retrospect that the spec never says plainly "The
AccessType determined for an attribute indicates how that attribute is
accessed by the persistence provider at runtime in terms of extracting and
injecting values...". You make that argument, but actually the spec never
says that.
On Wed, Mar 26, 2014 at 6:12 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
As a user I would not expect the @Access annotation to be treated as
a
special case by the framework in terms of when an annotation is
ignored, as for example that I can put this on either properties or
fields, and it would not be ignored, while other annotations could be
ignored depending on the position.
Also I highly doubt that there is a practical use case to "comment" a
mapping annotation by moving it to the wrong position (say I move a
@GeneratedValue from a field to a property when using FIELD access):
that would be extremely confusing to maintain.
The spec's wording states "When Access(PROPERTY) is applied to an
[...] mapping annotations **may** be placed on .."
I'd stress that it doesn' t say "must" but "may", and also
doesn't
seem to strictly ban the opposite.
As a user if I put a mapping annotation anywhere I expect it to be
respected, so I would expect the framework to work on the union of the
possible positions, and probably even to throw an exception on
conflicting options. The @Access property would then only be used to
state which access strategy should be used (and a nice effect is tha
the name becomes particularly self-explanatory too).
Also there are many types of possible contradictions in the mapping
options:
public class Course {
@Id @GeneratedValue(strategy=TABLE)
private long id;
...
@Id @GeneratedValue(strategy=SEQUENCE)
public long getId() {
return id;
}
Or you could have a stronger conflict which isn't solvable via
AccesType "rules" either:
public class Course {
@Id @GeneratedValue(strategy=TABLE)
@Access(AccessType.FIELD)
private long id;
...
@Id @GeneratedValue(strategy=SEQUENCE)
@Access(AccessType.PROPERTY)
public long getId() {
return id;
}
This last example is the reason why I think you should always
consistently look at both to collect mapping options, and possibly
throw runtime exceptions.
Sanne
On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org> wrote:
> >From the test
>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> we have the following:
>
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> private long id;
> ...
>
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> public long getId() {
> return id;
> }
> ...
> }
>
> The test asserts that this is a valid mapping. Granted that the spec is
> very unclear here, so I might be missing something. The pertinent spec
> section here states:
>
>
>
>
>
>
>
>
>
>
> *<quote>When Access(PROPERTY) is applied to an entity class, mapped
> superclass, or embeddableclass, mapping annotations may be placed on the
> properties of that class, and the persistenceprovider runtime accesses
> persistent state via the properties defined by that class. All
proper-ties
> that are not annotated with the Transient annotation are persistent.
> WhenAccess(PROPERTY) is applied to such a class, it is possible to
> selectively designate indi-vidual attributes within the class for
instance
> variable access. To specify a persistent instancevariable for access by
the
> persistence provider runtime, that instance variable must be desig-nated
> Access(FIELD).</quote>*
>
>
> I can see a few different ways to read that:
>
> 1) @Access can be placed on the attribute to define both where to look
for
> mapping annotations and the runtime access strategy for a given
attribute.
> Here, we'd do:
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> private long id;
> ...
>
> public long getId() {
> return id;
> }
> ...
> }
>
> 2) @Access can be placed on the attribute to define the runtime access
> strategy for a given attribute, but the class/hierarchy AccessType
controls
> where to look for mapping annotations. This would lead to:
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> @Access(AccessType.FIELD)
> private long id;
> ...
>
> @Id
> @GeneratedValue
> public long getId() {
> return id;
> }
> ...
> }
>
> The test seems to illustrate that our legacy code made yet a 3rd reading
of
> this passage such that @Access is still considered a "mapping annotation"
> even though that seems to directly contradict "To specify a persistent
> instance
> variable for access by the persistence provider runtime, that instance
> variable must be desig-
> nated Access(FIELD)."
>
>
> Is there some other passage I am missing that bears on what to do here?
> How do y'all feel about that passage and its implications on this test
> mapping?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:57 a.m.
Again from the spec (still discussing class-level Access(PROPERTY)) : "The
behavior is undefined if mapping annotations are placed on any instance
variables defined by the class for which Access(FIELD) is not specified".
Which to me implies that the expectation for switching access for a
particular field within such a class is to annotate the *field* with
Access(FIELD).
Also the footnote to this sections seems very relevant:
"[8] ... It is not permitted to specify a field as Access(PROPERTY) or a
property as Access(FIELD)..."
On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
My reading at the time and what I did find more intuitive is what
the
test represents.
Entity level @AccessType expresses where the annotations should
be. Otherwise the position of @Id is used to find the access type to
consider annotation wise.
If for a few attributes I wish to use the alternative property access, I
can add @AccessType next to the other annotations but expressing that
the actual property value access is based on the alternative access.
That way, all annotations are in the same place.
On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> As a user I would not expect the @Access annotation to be treated as a
> special case by the framework in terms of when an annotation is
> ignored, as for example that I can put this on either properties or
> fields, and it would not be ignored, while other annotations could be
> ignored depending on the position.
>
> Also I highly doubt that there is a practical use case to "comment" a
> mapping annotation by moving it to the wrong position (say I move a
> @GeneratedValue from a field to a property when using FIELD access):
> that would be extremely confusing to maintain.
>
> The spec's wording states "When Access(PROPERTY) is applied to an
> [...] mapping annotations **may** be placed on .."
> I'd stress that it doesn' t say "must" but "may", and
also doesn't
> seem to strictly ban the opposite.
>
> As a user if I put a mapping annotation anywhere I expect it to be
> respected, so I would expect the framework to work on the union of the
> possible positions, and probably even to throw an exception on
> conflicting options. The @Access property would then only be used to
> state which access strategy should be used (and a nice effect is tha
> the name becomes particularly self-explanatory too).
>
> Also there are many types of possible contradictions in the mapping
options:
>
> public class Course {
> @Id @GeneratedValue(strategy=TABLE)
> private long id;
> ...
>
> @Id @GeneratedValue(strategy=SEQUENCE)
> public long getId() {
> return id;
> }
>
> Or you could have a stronger conflict which isn't solvable via
> AccesType "rules" either:
>
> public class Course {
> @Id @GeneratedValue(strategy=TABLE)
> @Access(AccessType.FIELD)
> private long id;
> ...
>
> @Id @GeneratedValue(strategy=SEQUENCE)
> @Access(AccessType.PROPERTY)
> public long getId() {
> return id;
> }
>
> This last example is the reason why I think you should always
> consistently look at both to collect mapping options, and possibly
> throw runtime exceptions.
>
> Sanne
>
>
>
>
> On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org> wrote:
> > >From the test
> >
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> > we have the following:
> >
> >
> > @Entity
> > @Access(AccessType.PROPERTY)
> > public class Course3 {
> > private long id;
> > ...
> >
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > public long getId() {
> > return id;
> > }
> > ...
> > }
> >
> > The test asserts that this is a valid mapping. Granted that the spec
is
> > very unclear here, so I might be missing something. The pertinent spec
> > section here states:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *<quote>When Access(PROPERTY) is applied to an entity class, mapped
> > superclass, or embeddableclass, mapping annotations may be placed on
the
> > properties of that class, and the persistenceprovider runtime accesses
> > persistent state via the properties defined by that class. All
proper-ties
> > that are not annotated with the Transient annotation are persistent.
> > WhenAccess(PROPERTY) is applied to such a class, it is possible to
> > selectively designate indi-vidual attributes within the class for
instance
> > variable access. To specify a persistent instancevariable for access
by the
> > persistence provider runtime, that instance variable must be
desig-nated
> > Access(FIELD).</quote>*
> >
> >
> > I can see a few different ways to read that:
> >
> > 1) @Access can be placed on the attribute to define both where to look
for
> > mapping annotations and the runtime access strategy for a given
attribute.
> > Here, we'd do:
> >
> > @Entity
> > @Access(AccessType.PROPERTY)
> > public class Course3 {
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > private long id;
> > ...
> >
> > public long getId() {
> > return id;
> > }
> > ...
> > }
> >
> > 2) @Access can be placed on the attribute to define the runtime access
> > strategy for a given attribute, but the class/hierarchy AccessType
controls
> > where to look for mapping annotations. This would lead to:
> >
> > @Entity
> > @Access(AccessType.PROPERTY)
> > public class Course3 {
> > @Access(AccessType.FIELD)
> > private long id;
> > ...
> >
> > @Id
> > @GeneratedValue
> > public long getId() {
> > return id;
> > }
> > ...
> > }
> >
> > The test seems to illustrate that our legacy code made yet a 3rd
reading of
> > this passage such that @Access is still considered a "mapping
annotation"
> > even though that seems to directly contradict "To specify a persistent
> > instance
> > variable for access by the persistence provider runtime, that instance
> > variable must be desig-
> > nated Access(FIELD)."
> >
> >
> > Is there some other passage I am missing that bears on what to do here?
> > How do y'all feel about that passage and its implications on this test
> > mapping?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:56 a.m.
I do of course agree that people should use a single strategy and
stick to it, so I agree with your reading about what the "general
expectation" is.
But the original test represents a quite naturally looking example and
it's hard to justify why that should be considered illegal; I'd
probably be more inclined in making user's life easier than try to
lecture them about how a proper mapping should look like.
Ignoring any annotation leads to waste of time and debugging
frustration, so rather than silently discarding a mis-positioned
annotation I'd prefer a fail-fast approach; that said I think just
applying them all - as long as there are no obvious conflicting
annotations - would be even more user friendly and doesn't seem to
violate any specific wording of the spec.
Sanne
On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
Again from the spec (still discussing class-level Access(PROPERTY)) :
"The
behavior is undefined if mapping annotations are placed on any instance
variables defined by the class for which Access(FIELD) is not specified".
Which to me implies that the expectation for switching access for a
particular field within such a class is to annotate the *field* with
Access(FIELD).
Also the footnote to this sections seems very relevant:
"[8] ... It is not permitted to specify a field as Access(PROPERTY) or a
property as Access(FIELD)..."
On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>
> My reading at the time and what I did find more intuitive is what the
> test represents.
>
> Entity level @AccessType expresses where the annotations should
> be. Otherwise the position of @Id is used to find the access type to
> consider annotation wise.
>
> If for a few attributes I wish to use the alternative property access, I
> can add @AccessType next to the other annotations but expressing that
> the actual property value access is based on the alternative access.
> That way, all annotations are in the same place.
>
> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> > As a user I would not expect the @Access annotation to be treated as a
> > special case by the framework in terms of when an annotation is
> > ignored, as for example that I can put this on either properties or
> > fields, and it would not be ignored, while other annotations could be
> > ignored depending on the position.
> >
> > Also I highly doubt that there is a practical use case to "comment" a
> > mapping annotation by moving it to the wrong position (say I move a
> > @GeneratedValue from a field to a property when using FIELD access):
> > that would be extremely confusing to maintain.
> >
> > The spec's wording states "When Access(PROPERTY) is applied to an
> > [...] mapping annotations **may** be placed on .."
> > I'd stress that it doesn' t say "must" but "may",
and also doesn't
> > seem to strictly ban the opposite.
> >
> > As a user if I put a mapping annotation anywhere I expect it to be
> > respected, so I would expect the framework to work on the union of the
> > possible positions, and probably even to throw an exception on
> > conflicting options. The @Access property would then only be used to
> > state which access strategy should be used (and a nice effect is tha
> > the name becomes particularly self-explanatory too).
> >
> > Also there are many types of possible contradictions in the mapping
> > options:
> >
> > public class Course {
> > @Id @GeneratedValue(strategy=TABLE)
> > private long id;
> > ...
> >
> > @Id @GeneratedValue(strategy=SEQUENCE)
> > public long getId() {
> > return id;
> > }
> >
> > Or you could have a stronger conflict which isn't solvable via
> > AccesType "rules" either:
> >
> > public class Course {
> > @Id @GeneratedValue(strategy=TABLE)
> > @Access(AccessType.FIELD)
> > private long id;
> > ...
> >
> > @Id @GeneratedValue(strategy=SEQUENCE)
> > @Access(AccessType.PROPERTY)
> > public long getId() {
> > return id;
> > }
> >
> > This last example is the reason why I think you should always
> > consistently look at both to collect mapping options, and possibly
> > throw runtime exceptions.
> >
> > Sanne
> >
> >
> >
> >
> > On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org> wrote:
> > > >From the test
> > >
> > >
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> > > we have the following:
> > >
> > >
> > > @Entity
> > > @Access(AccessType.PROPERTY)
> > > public class Course3 {
> > > private long id;
> > > ...
> > >
> > > @Id
> > > @GeneratedValue
> > > @Access(AccessType.FIELD)
> > > public long getId() {
> > > return id;
> > > }
> > > ...
> > > }
> > >
> > > The test asserts that this is a valid mapping. Granted that the spec
> > > is
> > > very unclear here, so I might be missing something. The pertinent
> > > spec
> > > section here states:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *<quote>When Access(PROPERTY) is applied to an entity class, mapped
> > > superclass, or embeddableclass, mapping annotations may be placed on
> > > the
> > > properties of that class, and the persistenceprovider runtime accesses
> > > persistent state via the properties defined by that class. All
> > > proper-ties
> > > that are not annotated with the Transient annotation are persistent.
> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to
> > > selectively designate indi-vidual attributes within the class for
> > > instance
> > > variable access. To specify a persistent instancevariable for access
> > > by the
> > > persistence provider runtime, that instance variable must be
> > > desig-nated
> > > Access(FIELD).</quote>*
> > >
> > >
> > > I can see a few different ways to read that:
> > >
> > > 1) @Access can be placed on the attribute to define both where to look
> > > for
> > > mapping annotations and the runtime access strategy for a given
> > > attribute.
> > > Here, we'd do:
> > >
> > > @Entity
> > > @Access(AccessType.PROPERTY)
> > > public class Course3 {
> > > @Id
> > > @GeneratedValue
> > > @Access(AccessType.FIELD)
> > > private long id;
> > > ...
> > >
> > > public long getId() {
> > > return id;
> > > }
> > > ...
> > > }
> > >
> > > 2) @Access can be placed on the attribute to define the runtime access
> > > strategy for a given attribute, but the class/hierarchy AccessType
> > > controls
> > > where to look for mapping annotations. This would lead to:
> > >
> > > @Entity
> > > @Access(AccessType.PROPERTY)
> > > public class Course3 {
> > > @Access(AccessType.FIELD)
> > > private long id;
> > > ...
> > >
> > > @Id
> > > @GeneratedValue
> > > public long getId() {
> > > return id;
> > > }
> > > ...
> > > }
> > >
> > > The test seems to illustrate that our legacy code made yet a 3rd
> > > reading of
> > > this passage such that @Access is still considered a "mapping
> > > annotation"
> > > even though that seems to directly contradict "To specify a
persistent
> > > instance
> > > variable for access by the persistence provider runtime, that instance
> > > variable must be desig-
> > > nated Access(FIELD)."
> > >
> > >
> > > Is there some other passage I am missing that bears on what to do
> > > here?
> > > How do y'all feel about that passage and its implications on this
> > > test
> > > mapping?
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:12 a.m.
It does violate the spec though, that's the problem:
"... It is not permitted to specify a field as Access(PROPERTY) or a
property as Access(FIELD)..."
which imo is exactly what this is doing (specifying a property as FIELD):
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
I do of course agree that people should use a single strategy and
stick to it, so I agree with your reading about what the "general
expectation" is.
But the original test represents a quite naturally looking example and
it's hard to justify why that should be considered illegal; I'd
probably be more inclined in making user's life easier than try to
lecture them about how a proper mapping should look like.
Ignoring any annotation leads to waste of time and debugging
frustration, so rather than silently discarding a mis-positioned
annotation I'd prefer a fail-fast approach; that said I think just
applying them all - as long as there are no obvious conflicting
annotations - would be even more user friendly and doesn't seem to
violate any specific wording of the spec.
Sanne
On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
> Again from the spec (still discussing class-level Access(PROPERTY)) :
"The
> behavior is undefined if mapping annotations are placed on any instance
> variables defined by the class for which Access(FIELD) is not specified".
>
> Which to me implies that the expectation for switching access for a
> particular field within such a class is to annotate the *field* with
> Access(FIELD).
>
> Also the footnote to this sections seems very relevant:
>
> "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a
> property as Access(FIELD)..."
>
>
>
> On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
emmanuel(a)hibernate.org>
> wrote:
>>
>> My reading at the time and what I did find more intuitive is what the
>> test represents.
>>
>> Entity level @AccessType expresses where the annotations should
>> be. Otherwise the position of @Id is used to find the access type to
>> consider annotation wise.
>>
>> If for a few attributes I wish to use the alternative property access, I
>> can add @AccessType next to the other annotations but expressing that
>> the actual property value access is based on the alternative access.
>> That way, all annotations are in the same place.
>>
>> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
>> > As a user I would not expect the @Access annotation to be treated as a
>> > special case by the framework in terms of when an annotation is
>> > ignored, as for example that I can put this on either properties or
>> > fields, and it would not be ignored, while other annotations could be
>> > ignored depending on the position.
>> >
>> > Also I highly doubt that there is a practical use case to
"comment" a
>> > mapping annotation by moving it to the wrong position (say I move a
>> > @GeneratedValue from a field to a property when using FIELD access):
>> > that would be extremely confusing to maintain.
>> >
>> > The spec's wording states "When Access(PROPERTY) is applied to an
>> > [...] mapping annotations **may** be placed on .."
>> > I'd stress that it doesn' t say "must" but
"may", and also doesn't
>> > seem to strictly ban the opposite.
>> >
>> > As a user if I put a mapping annotation anywhere I expect it to be
>> > respected, so I would expect the framework to work on the union of the
>> > possible positions, and probably even to throw an exception on
>> > conflicting options. The @Access property would then only be used to
>> > state which access strategy should be used (and a nice effect is tha
>> > the name becomes particularly self-explanatory too).
>> >
>> > Also there are many types of possible contradictions in the mapping
>> > options:
>> >
>> > public class Course {
>> > @Id @GeneratedValue(strategy=TABLE)
>> > private long id;
>> > ...
>> >
>> > @Id @GeneratedValue(strategy=SEQUENCE)
>> > public long getId() {
>> > return id;
>> > }
>> >
>> > Or you could have a stronger conflict which isn't solvable via
>> > AccesType "rules" either:
>> >
>> > public class Course {
>> > @Id @GeneratedValue(strategy=TABLE)
>> > @Access(AccessType.FIELD)
>> > private long id;
>> > ...
>> >
>> > @Id @GeneratedValue(strategy=SEQUENCE)
>> > @Access(AccessType.PROPERTY)
>> > public long getId() {
>> > return id;
>> > }
>> >
>> > This last example is the reason why I think you should always
>> > consistently look at both to collect mapping options, and possibly
>> > throw runtime exceptions.
>> >
>> > Sanne
>> >
>> >
>> >
>> >
>> > On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org> wrote:
>> > > >From the test
>> > >
>> > >
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
>> > > we have the following:
>> > >
>> > >
>> > > @Entity
>> > > @Access(AccessType.PROPERTY)
>> > > public class Course3 {
>> > > private long id;
>> > > ...
>> > >
>> > > @Id
>> > > @GeneratedValue
>> > > @Access(AccessType.FIELD)
>> > > public long getId() {
>> > > return id;
>> > > }
>> > > ...
>> > > }
>> > >
>> > > The test asserts that this is a valid mapping. Granted that the
spec
>> > > is
>> > > very unclear here, so I might be missing something. The pertinent
>> > > spec
>> > > section here states:
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > *<quote>When Access(PROPERTY) is applied to an entity class,
mapped
>> > > superclass, or embeddableclass, mapping annotations may be placed on
>> > > the
>> > > properties of that class, and the persistenceprovider runtime
accesses
>> > > persistent state via the properties defined by that class. All
>> > > proper-ties
>> > > that are not annotated with the Transient annotation are persistent.
>> > > WhenAccess(PROPERTY) is applied to such a class, it is possible to
>> > > selectively designate indi-vidual attributes within the class for
>> > > instance
>> > > variable access. To specify a persistent instancevariable for access
>> > > by the
>> > > persistence provider runtime, that instance variable must be
>> > > desig-nated
>> > > Access(FIELD).</quote>*
>> > >
>> > >
>> > > I can see a few different ways to read that:
>> > >
>> > > 1) @Access can be placed on the attribute to define both where to
look
>> > > for
>> > > mapping annotations and the runtime access strategy for a given
>> > > attribute.
>> > > Here, we'd do:
>> > >
>> > > @Entity
>> > > @Access(AccessType.PROPERTY)
>> > > public class Course3 {
>> > > @Id
>> > > @GeneratedValue
>> > > @Access(AccessType.FIELD)
>> > > private long id;
>> > > ...
>> > >
>> > > public long getId() {
>> > > return id;
>> > > }
>> > > ...
>> > > }
>> > >
>> > > 2) @Access can be placed on the attribute to define the runtime
access
>> > > strategy for a given attribute, but the class/hierarchy AccessType
>> > > controls
>> > > where to look for mapping annotations. This would lead to:
>> > >
>> > > @Entity
>> > > @Access(AccessType.PROPERTY)
>> > > public class Course3 {
>> > > @Access(AccessType.FIELD)
>> > > private long id;
>> > > ...
>> > >
>> > > @Id
>> > > @GeneratedValue
>> > > public long getId() {
>> > > return id;
>> > > }
>> > > ...
>> > > }
>> > >
>> > > The test seems to illustrate that our legacy code made yet a 3rd
>> > > reading of
>> > > this passage such that @Access is still considered a "mapping
>> > > annotation"
>> > > even though that seems to directly contradict "To specify a
persistent
>> > > instance
>> > > variable for access by the persistence provider runtime, that
instance
>> > > variable must be desig-
>> > > nated Access(FIELD)."
>> > >
>> > >
>> > > Is there some other passage I am missing that bears on what to do
>> > > here?
>> > > How do y'all feel about that passage and its implications on
this
>> > > test
>> > > mapping?
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
12:14 p.m.
On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole <steve(a)hibernate.org>wrote:
It does violate the spec though, that's the problem:
Well it *could* be read to violate the spec. That's inherently the problem
with specs that use unclear wording; they can be read and argued multiple
ways.
"... It is not permitted to specify a field as Access(PROPERTY) or a
property as Access(FIELD)..."
which imo is exactly what this is doing (specifying a property as FIELD):
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
> I do of course agree that people should use a single strategy and
> stick to it, so I agree with your reading about what the "general
> expectation" is.
>
> But the original test represents a quite naturally looking example and
> it's hard to justify why that should be considered illegal; I'd
> probably be more inclined in making user's life easier than try to
> lecture them about how a proper mapping should look like.
>
> Ignoring any annotation leads to waste of time and debugging
> frustration, so rather than silently discarding a mis-positioned
> annotation I'd prefer a fail-fast approach; that said I think just
> applying them all - as long as there are no obvious conflicting
> annotations - would be even more user friendly and doesn't seem to
> violate any specific wording of the spec.
>
> Sanne
>
>
> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
> > Again from the spec (still discussing class-level Access(PROPERTY)) :
> "The
> > behavior is undefined if mapping annotations are placed on any instance
> > variables defined by the class for which Access(FIELD) is not
> specified".
> >
> > Which to me implies that the expectation for switching access for a
> > particular field within such a class is to annotate the *field* with
> > Access(FIELD).
> >
> > Also the footnote to this sections seems very relevant:
> >
> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or a
> > property as Access(FIELD)..."
> >
> >
> >
> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
> emmanuel(a)hibernate.org>
> > wrote:
> >>
> >> My reading at the time and what I did find more intuitive is what the
> >> test represents.
> >>
> >> Entity level @AccessType expresses where the annotations should
> >> be. Otherwise the position of @Id is used to find the access type to
> >> consider annotation wise.
> >>
> >> If for a few attributes I wish to use the alternative property access,
> I
> >> can add @AccessType next to the other annotations but expressing that
> >> the actual property value access is based on the alternative access.
> >> That way, all annotations are in the same place.
> >>
> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> >> > As a user I would not expect the @Access annotation to be treated as
> a
> >> > special case by the framework in terms of when an annotation is
> >> > ignored, as for example that I can put this on either properties or
> >> > fields, and it would not be ignored, while other annotations could be
> >> > ignored depending on the position.
> >> >
> >> > Also I highly doubt that there is a practical use case to
"comment" a
> >> > mapping annotation by moving it to the wrong position (say I move a
> >> > @GeneratedValue from a field to a property when using FIELD access):
> >> > that would be extremely confusing to maintain.
> >> >
> >> > The spec's wording states "When Access(PROPERTY) is applied to
an
> >> > [...] mapping annotations **may** be placed on .."
> >> > I'd stress that it doesn' t say "must" but
"may", and also doesn't
> >> > seem to strictly ban the opposite.
> >> >
> >> > As a user if I put a mapping annotation anywhere I expect it to be
> >> > respected, so I would expect the framework to work on the union of
> the
> >> > possible positions, and probably even to throw an exception on
> >> > conflicting options. The @Access property would then only be used to
> >> > state which access strategy should be used (and a nice effect is tha
> >> > the name becomes particularly self-explanatory too).
> >> >
> >> > Also there are many types of possible contradictions in the mapping
> >> > options:
> >> >
> >> > public class Course {
> >> > @Id @GeneratedValue(strategy=TABLE)
> >> > private long id;
> >> > ...
> >> >
> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> > public long getId() {
> >> > return id;
> >> > }
> >> >
> >> > Or you could have a stronger conflict which isn't solvable via
> >> > AccesType "rules" either:
> >> >
> >> > public class Course {
> >> > @Id @GeneratedValue(strategy=TABLE)
> >> > @Access(AccessType.FIELD)
> >> > private long id;
> >> > ...
> >> >
> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> > @Access(AccessType.PROPERTY)
> >> > public long getId() {
> >> > return id;
> >> > }
> >> >
> >> > This last example is the reason why I think you should always
> >> > consistently look at both to collect mapping options, and possibly
> >> > throw runtime exceptions.
> >> >
> >> > Sanne
> >> >
> >> >
> >> >
> >> >
> >> > On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org>
wrote:
> >> > > >From the test
> >> > >
> >> > >
>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> >> > > we have the following:
> >> > >
> >> > >
> >> > > @Entity
> >> > > @Access(AccessType.PROPERTY)
> >> > > public class Course3 {
> >> > > private long id;
> >> > > ...
> >> > >
> >> > > @Id
> >> > > @GeneratedValue
> >> > > @Access(AccessType.FIELD)
> >> > > public long getId() {
> >> > > return id;
> >> > > }
> >> > > ...
> >> > > }
> >> > >
> >> > > The test asserts that this is a valid mapping. Granted that the
> spec
> >> > > is
> >> > > very unclear here, so I might be missing something. The
pertinent
> >> > > spec
> >> > > section here states:
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > *<quote>When Access(PROPERTY) is applied to an entity class,
mapped
> >> > > superclass, or embeddableclass, mapping annotations may be placed
> on
> >> > > the
> >> > > properties of that class, and the persistenceprovider runtime
> accesses
> >> > > persistent state via the properties defined by that class. All
> >> > > proper-ties
> >> > > that are not annotated with the Transient annotation are
> persistent.
> >> > > WhenAccess(PROPERTY) is applied to such a class, it is possible
to
> >> > > selectively designate indi-vidual attributes within the class for
> >> > > instance
> >> > > variable access. To specify a persistent instancevariable for
> access
> >> > > by the
> >> > > persistence provider runtime, that instance variable must be
> >> > > desig-nated
> >> > > Access(FIELD).</quote>*
> >> > >
> >> > >
> >> > > I can see a few different ways to read that:
> >> > >
> >> > > 1) @Access can be placed on the attribute to define both where to
> look
> >> > > for
> >> > > mapping annotations and the runtime access strategy for a given
> >> > > attribute.
> >> > > Here, we'd do:
> >> > >
> >> > > @Entity
> >> > > @Access(AccessType.PROPERTY)
> >> > > public class Course3 {
> >> > > @Id
> >> > > @GeneratedValue
> >> > > @Access(AccessType.FIELD)
> >> > > private long id;
> >> > > ...
> >> > >
> >> > > public long getId() {
> >> > > return id;
> >> > > }
> >> > > ...
> >> > > }
> >> > >
> >> > > 2) @Access can be placed on the attribute to define the runtime
> access
> >> > > strategy for a given attribute, but the class/hierarchy
AccessType
> >> > > controls
> >> > > where to look for mapping annotations. This would lead to:
> >> > >
> >> > > @Entity
> >> > > @Access(AccessType.PROPERTY)
> >> > > public class Course3 {
> >> > > @Access(AccessType.FIELD)
> >> > > private long id;
> >> > > ...
> >> > >
> >> > > @Id
> >> > > @GeneratedValue
> >> > > public long getId() {
> >> > > return id;
> >> > > }
> >> > > ...
> >> > > }
> >> > >
> >> > > The test seems to illustrate that our legacy code made yet a 3rd
> >> > > reading of
> >> > > this passage such that @Access is still considered a
"mapping
> >> > > annotation"
> >> > > even though that seems to directly contradict "To specify a
> persistent
> >> > > instance
> >> > > variable for access by the persistence provider runtime, that
> instance
> >> > > variable must be desig-
> >> > > nated Access(FIELD)."
> >> > >
> >> > >
> >> > > Is there some other passage I am missing that bears on what to do
> >> > > here?
> >> > > How do y'all feel about that passage and its implications on
this
> >> > > test
> >> > > mapping?
> >> > > _______________________________________________
> >> > > hibernate-dev mailing list
> >> > > hibernate-dev(a)lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
12:21 p.m.
My take on the spec as always been that I'd rather follow the intent,
the common sense above the letter. Likewise, I favored user experience
over spec strict adherence.
I did clash numerous time with the TCK in these targets but I still
prefer that over just doing something stupid but spec to the letter.
(this is general and not specific to that case).
Anyway so my take is pretty much as it was when I first implemented
@AccessType even if it steps over the spec at the margin.
BTW I'm also happy if we all decide I made a usability mistake that should be fixed.
Emmanuel
On Wed 2014-03-26 11:14, Steve Ebersole wrote:
On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole
<steve(a)hibernate.org>wrote:
> It does violate the spec though, that's the problem:
>
Well it *could* be read to violate the spec. That's inherently the problem
with specs that use unclear wording; they can be read and argued multiple
ways.
>
> "... It is not permitted to specify a field as Access(PROPERTY) or a
> property as Access(FIELD)..."
>
> which imo is exactly what this is doing (specifying a property as FIELD):
>
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> public long getId() {
> return id;
> }
>
>
>
> On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
>
>> I do of course agree that people should use a single strategy and
>> stick to it, so I agree with your reading about what the "general
>> expectation" is.
>>
>> But the original test represents a quite naturally looking example and
>> it's hard to justify why that should be considered illegal; I'd
>> probably be more inclined in making user's life easier than try to
>> lecture them about how a proper mapping should look like.
>>
>> Ignoring any annotation leads to waste of time and debugging
>> frustration, so rather than silently discarding a mis-positioned
>> annotation I'd prefer a fail-fast approach; that said I think just
>> applying them all - as long as there are no obvious conflicting
>> annotations - would be even more user friendly and doesn't seem to
>> violate any specific wording of the spec.
>>
>> Sanne
>>
>>
>> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
>> > Again from the spec (still discussing class-level Access(PROPERTY)) :
>> "The
>> > behavior is undefined if mapping annotations are placed on any instance
>> > variables defined by the class for which Access(FIELD) is not
>> specified".
>> >
>> > Which to me implies that the expectation for switching access for a
>> > particular field within such a class is to annotate the *field* with
>> > Access(FIELD).
>> >
>> > Also the footnote to this sections seems very relevant:
>> >
>> > "[8] ... It is not permitted to specify a field as Access(PROPERTY) or
a
>> > property as Access(FIELD)..."
>> >
>> >
>> >
>> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
>> emmanuel(a)hibernate.org>
>> > wrote:
>> >>
>> >> My reading at the time and what I did find more intuitive is what the
>> >> test represents.
>> >>
>> >> Entity level @AccessType expresses where the annotations should
>> >> be. Otherwise the position of @Id is used to find the access type to
>> >> consider annotation wise.
>> >>
>> >> If for a few attributes I wish to use the alternative property access,
>> I
>> >> can add @AccessType next to the other annotations but expressing that
>> >> the actual property value access is based on the alternative access.
>> >> That way, all annotations are in the same place.
>> >>
>> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
>> >> > As a user I would not expect the @Access annotation to be treated
as
>> a
>> >> > special case by the framework in terms of when an annotation is
>> >> > ignored, as for example that I can put this on either properties
or
>> >> > fields, and it would not be ignored, while other annotations could
be
>> >> > ignored depending on the position.
>> >> >
>> >> > Also I highly doubt that there is a practical use case to
"comment" a
>> >> > mapping annotation by moving it to the wrong position (say I move
a
>> >> > @GeneratedValue from a field to a property when using FIELD
access):
>> >> > that would be extremely confusing to maintain.
>> >> >
>> >> > The spec's wording states "When Access(PROPERTY) is
applied to an
>> >> > [...] mapping annotations **may** be placed on .."
>> >> > I'd stress that it doesn' t say "must" but
"may", and also doesn't
>> >> > seem to strictly ban the opposite.
>> >> >
>> >> > As a user if I put a mapping annotation anywhere I expect it to
be
>> >> > respected, so I would expect the framework to work on the union
of
>> the
>> >> > possible positions, and probably even to throw an exception on
>> >> > conflicting options. The @Access property would then only be used
to
>> >> > state which access strategy should be used (and a nice effect is
tha
>> >> > the name becomes particularly self-explanatory too).
>> >> >
>> >> > Also there are many types of possible contradictions in the
mapping
>> >> > options:
>> >> >
>> >> > public class Course {
>> >> > @Id @GeneratedValue(strategy=TABLE)
>> >> > private long id;
>> >> > ...
>> >> >
>> >> > @Id @GeneratedValue(strategy=SEQUENCE)
>> >> > public long getId() {
>> >> > return id;
>> >> > }
>> >> >
>> >> > Or you could have a stronger conflict which isn't solvable
via
>> >> > AccesType "rules" either:
>> >> >
>> >> > public class Course {
>> >> > @Id @GeneratedValue(strategy=TABLE)
>> >> > @Access(AccessType.FIELD)
>> >> > private long id;
>> >> > ...
>> >> >
>> >> > @Id @GeneratedValue(strategy=SEQUENCE)
>> >> > @Access(AccessType.PROPERTY)
>> >> > public long getId() {
>> >> > return id;
>> >> > }
>> >> >
>> >> > This last example is the reason why I think you should always
>> >> > consistently look at both to collect mapping options, and
possibly
>> >> > throw runtime exceptions.
>> >> >
>> >> > Sanne
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 26 March 2014 04:13, Steve Ebersole <steve(a)hibernate.org>
wrote:
>> >> > > >From the test
>> >> > >
>> >> > >
>>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
>> >> > > we have the following:
>> >> > >
>> >> > >
>> >> > > @Entity
>> >> > > @Access(AccessType.PROPERTY)
>> >> > > public class Course3 {
>> >> > > private long id;
>> >> > > ...
>> >> > >
>> >> > > @Id
>> >> > > @GeneratedValue
>> >> > > @Access(AccessType.FIELD)
>> >> > > public long getId() {
>> >> > > return id;
>> >> > > }
>> >> > > ...
>> >> > > }
>> >> > >
>> >> > > The test asserts that this is a valid mapping. Granted that
the
>> spec
>> >> > > is
>> >> > > very unclear here, so I might be missing something. The
pertinent
>> >> > > spec
>> >> > > section here states:
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > *<quote>When Access(PROPERTY) is applied to an entity
class, mapped
>> >> > > superclass, or embeddableclass, mapping annotations may be
placed
>> on
>> >> > > the
>> >> > > properties of that class, and the persistenceprovider
runtime
>> accesses
>> >> > > persistent state via the properties defined by that class.
All
>> >> > > proper-ties
>> >> > > that are not annotated with the Transient annotation are
>> persistent.
>> >> > > WhenAccess(PROPERTY) is applied to such a class, it is
possible to
>> >> > > selectively designate indi-vidual attributes within the class
for
>> >> > > instance
>> >> > > variable access. To specify a persistent instancevariable
for
>> access
>> >> > > by the
>> >> > > persistence provider runtime, that instance variable must be
>> >> > > desig-nated
>> >> > > Access(FIELD).</quote>*
>> >> > >
>> >> > >
>> >> > > I can see a few different ways to read that:
>> >> > >
>> >> > > 1) @Access can be placed on the attribute to define both
where to
>> look
>> >> > > for
>> >> > > mapping annotations and the runtime access strategy for a
given
>> >> > > attribute.
>> >> > > Here, we'd do:
>> >> > >
>> >> > > @Entity
>> >> > > @Access(AccessType.PROPERTY)
>> >> > > public class Course3 {
>> >> > > @Id
>> >> > > @GeneratedValue
>> >> > > @Access(AccessType.FIELD)
>> >> > > private long id;
>> >> > > ...
>> >> > >
>> >> > > public long getId() {
>> >> > > return id;
>> >> > > }
>> >> > > ...
>> >> > > }
>> >> > >
>> >> > > 2) @Access can be placed on the attribute to define the
runtime
>> access
>> >> > > strategy for a given attribute, but the class/hierarchy
AccessType
>> >> > > controls
>> >> > > where to look for mapping annotations. This would lead to:
>> >> > >
>> >> > > @Entity
>> >> > > @Access(AccessType.PROPERTY)
>> >> > > public class Course3 {
>> >> > > @Access(AccessType.FIELD)
>> >> > > private long id;
>> >> > > ...
>> >> > >
>> >> > > @Id
>> >> > > @GeneratedValue
>> >> > > public long getId() {
>> >> > > return id;
>> >> > > }
>> >> > > ...
>> >> > > }
>> >> > >
>> >> > > The test seems to illustrate that our legacy code made yet a
3rd
>> >> > > reading of
>> >> > > this passage such that @Access is still considered a
"mapping
>> >> > > annotation"
>> >> > > even though that seems to directly contradict "To
specify a
>> persistent
>> >> > > instance
>> >> > > variable for access by the persistence provider runtime,
that
>> instance
>> >> > > variable must be desig-
>> >> > > nated Access(FIELD)."
>> >> > >
>> >> > >
>> >> > > Is there some other passage I am missing that bears on what
to do
>> >> > > here?
>> >> > > How do y'all feel about that passage and its
implications on this
>> >> > > test
>> >> > > mapping?
>> >> > > _______________________________________________
>> >> > > hibernate-dev mailing list
>> >> > > hibernate-dev(a)lists.jboss.org
>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev(a)lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>>
>
>
2:37 p.m.
My point is that I do not find annotating a getter method with
@Access(FIELD) to be inherently common sense. It really boils down to the
purpose/intent of @Access. If @Access *at the attribute level* is
ultimately *just* indicating how to extract/inject then I think
@Access(FIELD) on the getter does make sense. If @Access *at the attribute
level* also directs where to look for annotations (consistent with @Access
at class/hierarchy-level) then I think @AccessFile needs to be on the field
along with the other annotations, assuming we stay with non-mixed placement
for an attribute.
So let's decide that first. Since the spec does not say clearly one way or
the other, I guess we have some leeway here.
https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and
@IdSetter) plays in here as well.
On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org>wrote:
My take on the spec as always been that I'd rather follow the
intent,
the common sense above the letter. Likewise, I favored user experience
over spec strict adherence.
I did clash numerous time with the TCK in these targets but I still
prefer that over just doing something stupid but spec to the letter.
(this is general and not specific to that case).
Anyway so my take is pretty much as it was when I first implemented
@AccessType even if it steps over the spec at the margin.
BTW I'm also happy if we all decide I made a usability mistake that should
be fixed.
Emmanuel
On Wed 2014-03-26 11:14, Steve Ebersole wrote:
> On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole <steve(a)hibernate.org
>wrote:
>
> > It does violate the spec though, that's the problem:
> >
>
> Well it *could* be read to violate the spec. That's inherently the
problem
> with specs that use unclear wording; they can be read and argued multiple
> ways.
>
>
>
> >
> > "... It is not permitted to specify a field as Access(PROPERTY) or a
> > property as Access(FIELD)..."
> >
> > which imo is exactly what this is doing (specifying a property as
FIELD):
> >
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > public long getId() {
> > return id;
> > }
> >
> >
> >
> > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero <sanne(a)hibernate.org
>wrote:
> >
> >> I do of course agree that people should use a single strategy and
> >> stick to it, so I agree with your reading about what the "general
> >> expectation" is.
> >>
> >> But the original test represents a quite naturally looking example and
> >> it's hard to justify why that should be considered illegal; I'd
> >> probably be more inclined in making user's life easier than try to
> >> lecture them about how a proper mapping should look like.
> >>
> >> Ignoring any annotation leads to waste of time and debugging
> >> frustration, so rather than silently discarding a mis-positioned
> >> annotation I'd prefer a fail-fast approach; that said I think just
> >> applying them all - as long as there are no obvious conflicting
> >> annotations - would be even more user friendly and doesn't seem to
> >> violate any specific wording of the spec.
> >>
> >> Sanne
> >>
> >>
> >> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
> >> > Again from the spec (still discussing class-level Access(PROPERTY))
:
> >> "The
> >> > behavior is undefined if mapping annotations are placed on any
instance
> >> > variables defined by the class for which Access(FIELD) is not
> >> specified".
> >> >
> >> > Which to me implies that the expectation for switching access for a
> >> > particular field within such a class is to annotate the *field* with
> >> > Access(FIELD).
> >> >
> >> > Also the footnote to this sections seems very relevant:
> >> >
> >> > "[8] ... It is not permitted to specify a field as
Access(PROPERTY)
or a
> >> > property as Access(FIELD)..."
> >> >
> >> >
> >> >
> >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
> >> emmanuel(a)hibernate.org>
> >> > wrote:
> >> >>
> >> >> My reading at the time and what I did find more intuitive is what
the
> >> >> test represents.
> >> >>
> >> >> Entity level @AccessType expresses where the annotations should
> >> >> be. Otherwise the position of @Id is used to find the access type
to
> >> >> consider annotation wise.
> >> >>
> >> >> If for a few attributes I wish to use the alternative property
access,
> >> I
> >> >> can add @AccessType next to the other annotations but expressing
that
> >> >> the actual property value access is based on the alternative
access.
> >> >> That way, all annotations are in the same place.
> >> >>
> >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> >> >> > As a user I would not expect the @Access annotation to be
treated as
> >> a
> >> >> > special case by the framework in terms of when an annotation
is
> >> >> > ignored, as for example that I can put this on either
properties
or
> >> >> > fields, and it would not be ignored, while other annotations
could be
> >> >> > ignored depending on the position.
> >> >> >
> >> >> > Also I highly doubt that there is a practical use case to
"comment" a
> >> >> > mapping annotation by moving it to the wrong position (say I
move a
> >> >> > @GeneratedValue from a field to a property when using FIELD
access):
> >> >> > that would be extremely confusing to maintain.
> >> >> >
> >> >> > The spec's wording states "When Access(PROPERTY) is
applied to an
> >> >> > [...] mapping annotations **may** be placed on .."
> >> >> > I'd stress that it doesn' t say "must" but
"may", and also
doesn't
> >> >> > seem to strictly ban the opposite.
> >> >> >
> >> >> > As a user if I put a mapping annotation anywhere I expect it
to
be
> >> >> > respected, so I would expect the framework to work on the
union
of
> >> the
> >> >> > possible positions, and probably even to throw an exception
on
> >> >> > conflicting options. The @Access property would then only be
used to
> >> >> > state which access strategy should be used (and a nice effect
is
tha
> >> >> > the name becomes particularly self-explanatory too).
> >> >> >
> >> >> > Also there are many types of possible contradictions in the
mapping
> >> >> > options:
> >> >> >
> >> >> > public class Course {
> >> >> > @Id @GeneratedValue(strategy=TABLE)
> >> >> > private long id;
> >> >> > ...
> >> >> >
> >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> >> > public long getId() {
> >> >> > return id;
> >> >> > }
> >> >> >
> >> >> > Or you could have a stronger conflict which isn't
solvable via
> >> >> > AccesType "rules" either:
> >> >> >
> >> >> > public class Course {
> >> >> > @Id @GeneratedValue(strategy=TABLE)
> >> >> > @Access(AccessType.FIELD)
> >> >> > private long id;
> >> >> > ...
> >> >> >
> >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> >> > @Access(AccessType.PROPERTY)
> >> >> > public long getId() {
> >> >> > return id;
> >> >> > }
> >> >> >
> >> >> > This last example is the reason why I think you should
always
> >> >> > consistently look at both to collect mapping options, and
possibly
> >> >> > throw runtime exceptions.
> >> >> >
> >> >> > Sanne
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org>
wrote:
> >> >> > > >From the test
> >> >> > >
> >> >> > >
> >>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> >> >> > > we have the following:
> >> >> > >
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > The test asserts that this is a valid mapping. Granted
that
the
> >> spec
> >> >> > > is
> >> >> > > very unclear here, so I might be missing something.
The
pertinent
> >> >> > > spec
> >> >> > > section here states:
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > *<quote>When Access(PROPERTY) is applied to an
entity class,
mapped
> >> >> > > superclass, or embeddableclass, mapping annotations may
be
placed
> >> on
> >> >> > > the
> >> >> > > properties of that class, and the persistenceprovider
runtime
> >> accesses
> >> >> > > persistent state via the properties defined by that
class. All
> >> >> > > proper-ties
> >> >> > > that are not annotated with the Transient annotation
are
> >> persistent.
> >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is
possible to
> >> >> > > selectively designate indi-vidual attributes within the
class
for
> >> >> > > instance
> >> >> > > variable access. To specify a persistent
instancevariable for
> >> access
> >> >> > > by the
> >> >> > > persistence provider runtime, that instance variable
must be
> >> >> > > desig-nated
> >> >> > > Access(FIELD).</quote>*
> >> >> > >
> >> >> > >
> >> >> > > I can see a few different ways to read that:
> >> >> > >
> >> >> > > 1) @Access can be placed on the attribute to define both
where
to
> >> look
> >> >> > > for
> >> >> > > mapping annotations and the runtime access strategy for
a given
> >> >> > > attribute.
> >> >> > > Here, we'd do:
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > 2) @Access can be placed on the attribute to define the
runtime
> >> access
> >> >> > > strategy for a given attribute, but the class/hierarchy
AccessType
> >> >> > > controls
> >> >> > > where to look for mapping annotations. This would lead
to:
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > The test seems to illustrate that our legacy code made
yet a
3rd
> >> >> > > reading of
> >> >> > > this passage such that @Access is still considered a
"mapping
> >> >> > > annotation"
> >> >> > > even though that seems to directly contradict "To
specify a
> >> persistent
> >> >> > > instance
> >> >> > > variable for access by the persistence provider runtime,
that
> >> instance
> >> >> > > variable must be desig-
> >> >> > > nated Access(FIELD)."
> >> >> > >
> >> >> > >
> >> >> > > Is there some other passage I am missing that bears on
what to
do
> >> >> > > here?
> >> >> > > How do y'all feel about that passage and its
implications on
this
> >> >> > > test
> >> >> > > mapping?
> >> >> > > _______________________________________________
> >> >> > > hibernate-dev mailing list
> >> >> > > hibernate-dev(a)lists.jboss.org
> >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev(a)lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >>
> >
> >
2:42 p.m.
On 26 March 2014 18:37, Steve Ebersole <steve(a)hibernate.org> wrote:
My point is that I do not find annotating a getter method with
@Access(FIELD) to be inherently common sense. It really boils down to the
purpose/intent of @Access. If @Access *at the attribute level* is
ultimately *just* indicating how to extract/inject then I think
@Access(FIELD) on the getter does make sense. If @Access *at the attribute
level* also directs where to look for annotations (consistent with @Access
at class/hierarchy-level) then I think @AccessFile needs to be on the field
along with the other annotations, assuming we stay with non-mixed placement
for an attribute.
Here a use case: as convention the team likes to put all annotations
on getters, but then for some specific reason a field needs to be
configured to have the ORM to use field access.
Seems fair enough?
Sanne
So let's decide that first. Since the spec does not say clearly one way or
the other, I guess we have some leeway here.
https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and
@IdSetter) plays in here as well.
On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>
> My take on the spec as always been that I'd rather follow the intent,
> the common sense above the letter. Likewise, I favored user experience
> over spec strict adherence.
> I did clash numerous time with the TCK in these targets but I still
> prefer that over just doing something stupid but spec to the letter.
> (this is general and not specific to that case).
>
> Anyway so my take is pretty much as it was when I first implemented
> @AccessType even if it steps over the spec at the margin.
> BTW I'm also happy if we all decide I made a usability mistake that should
> be fixed.
>
> Emmanuel
>
> On Wed 2014-03-26 11:14, Steve Ebersole wrote:
> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole
> > <steve(a)hibernate.org>wrote:
> >
> > > It does violate the spec though, that's the problem:
> > >
> >
> > Well it *could* be read to violate the spec. That's inherently the
> > problem
> > with specs that use unclear wording; they can be read and argued
> > multiple
> > ways.
> >
> >
> >
> > >
> > > "... It is not permitted to specify a field as Access(PROPERTY) or a
> > > property as Access(FIELD)..."
> > >
> > > which imo is exactly what this is doing (specifying a property as
> > > FIELD):
> > >
> > > @Id
> > > @GeneratedValue
> > > @Access(AccessType.FIELD)
> > > public long getId() {
> > > return id;
> > > }
> > >
> > >
> > >
> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero
> > > <sanne(a)hibernate.org>wrote:
> > >
> > >> I do of course agree that people should use a single strategy and
> > >> stick to it, so I agree with your reading about what the "general
> > >> expectation" is.
> > >>
> > >> But the original test represents a quite naturally looking example
> > >> and
> > >> it's hard to justify why that should be considered illegal;
I'd
> > >> probably be more inclined in making user's life easier than try to
> > >> lecture them about how a proper mapping should look like.
> > >>
> > >> Ignoring any annotation leads to waste of time and debugging
> > >> frustration, so rather than silently discarding a mis-positioned
> > >> annotation I'd prefer a fail-fast approach; that said I think just
> > >> applying them all - as long as there are no obvious conflicting
> > >> annotations - would be even more user friendly and doesn't seem to
> > >> violate any specific wording of the spec.
> > >>
> > >> Sanne
> > >>
> > >>
> > >> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org>
wrote:
> > >> > Again from the spec (still discussing class-level
Access(PROPERTY))
> > >> > :
> > >> "The
> > >> > behavior is undefined if mapping annotations are placed on any
> > >> > instance
> > >> > variables defined by the class for which Access(FIELD) is not
> > >> specified".
> > >> >
> > >> > Which to me implies that the expectation for switching access for
a
> > >> > particular field within such a class is to annotate the *field*
> > >> > with
> > >> > Access(FIELD).
> > >> >
> > >> > Also the footnote to this sections seems very relevant:
> > >> >
> > >> > "[8] ... It is not permitted to specify a field as
Access(PROPERTY)
> > >> > or a
> > >> > property as Access(FIELD)..."
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
> > >> emmanuel(a)hibernate.org>
> > >> > wrote:
> > >> >>
> > >> >> My reading at the time and what I did find more intuitive is
what
> > >> >> the
> > >> >> test represents.
> > >> >>
> > >> >> Entity level @AccessType expresses where the annotations
should
> > >> >> be. Otherwise the position of @Id is used to find the access
type
> > >> >> to
> > >> >> consider annotation wise.
> > >> >>
> > >> >> If for a few attributes I wish to use the alternative
property
> > >> >> access,
> > >> I
> > >> >> can add @AccessType next to the other annotations but
expressing
> > >> >> that
> > >> >> the actual property value access is based on the alternative
> > >> >> access.
> > >> >> That way, all annotations are in the same place.
> > >> >>
> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> > >> >> > As a user I would not expect the @Access annotation to
be
> > >> >> > treated as
> > >> a
> > >> >> > special case by the framework in terms of when an
annotation is
> > >> >> > ignored, as for example that I can put this on either
properties
> > >> >> > or
> > >> >> > fields, and it would not be ignored, while other
annotations
> > >> >> > could be
> > >> >> > ignored depending on the position.
> > >> >> >
> > >> >> > Also I highly doubt that there is a practical use case
to
> > >> >> > "comment" a
> > >> >> > mapping annotation by moving it to the wrong position
(say I
> > >> >> > move a
> > >> >> > @GeneratedValue from a field to a property when using
FIELD
> > >> >> > access):
> > >> >> > that would be extremely confusing to maintain.
> > >> >> >
> > >> >> > The spec's wording states "When Access(PROPERTY)
is applied to
> > >> >> > an
> > >> >> > [...] mapping annotations **may** be placed on .."
> > >> >> > I'd stress that it doesn' t say "must"
but "may", and also
> > >> >> > doesn't
> > >> >> > seem to strictly ban the opposite.
> > >> >> >
> > >> >> > As a user if I put a mapping annotation anywhere I expect
it to
> > >> >> > be
> > >> >> > respected, so I would expect the framework to work on the
union
> > >> >> > of
> > >> the
> > >> >> > possible positions, and probably even to throw an
exception on
> > >> >> > conflicting options. The @Access property would then only
be
> > >> >> > used to
> > >> >> > state which access strategy should be used (and a nice
effect is
> > >> >> > tha
> > >> >> > the name becomes particularly self-explanatory too).
> > >> >> >
> > >> >> > Also there are many types of possible contradictions in
the
> > >> >> > mapping
> > >> >> > options:
> > >> >> >
> > >> >> > public class Course {
> > >> >> > @Id @GeneratedValue(strategy=TABLE)
> > >> >> > private long id;
> > >> >> > ...
> > >> >> >
> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> > >> >> > public long getId() {
> > >> >> > return id;
> > >> >> > }
> > >> >> >
> > >> >> > Or you could have a stronger conflict which isn't
solvable via
> > >> >> > AccesType "rules" either:
> > >> >> >
> > >> >> > public class Course {
> > >> >> > @Id @GeneratedValue(strategy=TABLE)
> > >> >> > @Access(AccessType.FIELD)
> > >> >> > private long id;
> > >> >> > ...
> > >> >> >
> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> > >> >> > @Access(AccessType.PROPERTY)
> > >> >> > public long getId() {
> > >> >> > return id;
> > >> >> > }
> > >> >> >
> > >> >> > This last example is the reason why I think you should
always
> > >> >> > consistently look at both to collect mapping options,
and
> > >> >> > possibly
> > >> >> > throw runtime exceptions.
> > >> >> >
> > >> >> > Sanne
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org>
> > >> >> > wrote:
> > >> >> > > >From the test
> > >> >> > >
> > >> >> > >
> > >>
> > >>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> > >> >> > > we have the following:
> > >> >> > >
> > >> >> > >
> > >> >> > > @Entity
> > >> >> > > @Access(AccessType.PROPERTY)
> > >> >> > > public class Course3 {
> > >> >> > > private long id;
> > >> >> > > ...
> > >> >> > >
> > >> >> > > @Id
> > >> >> > > @GeneratedValue
> > >> >> > > @Access(AccessType.FIELD)
> > >> >> > > public long getId() {
> > >> >> > > return id;
> > >> >> > > }
> > >> >> > > ...
> > >> >> > > }
> > >> >> > >
> > >> >> > > The test asserts that this is a valid mapping.
Granted that
> > >> >> > > the
> > >> spec
> > >> >> > > is
> > >> >> > > very unclear here, so I might be missing something.
The
> > >> >> > > pertinent
> > >> >> > > spec
> > >> >> > > section here states:
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > *<quote>When Access(PROPERTY) is applied to an
entity class,
> > >> >> > > mapped
> > >> >> > > superclass, or embeddableclass, mapping annotations
may be
> > >> >> > > placed
> > >> on
> > >> >> > > the
> > >> >> > > properties of that class, and the
persistenceprovider runtime
> > >> accesses
> > >> >> > > persistent state via the properties defined by that
class. All
> > >> >> > > proper-ties
> > >> >> > > that are not annotated with the Transient annotation
are
> > >> persistent.
> > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it
is
> > >> >> > > possible to
> > >> >> > > selectively designate indi-vidual attributes within
the class
> > >> >> > > for
> > >> >> > > instance
> > >> >> > > variable access. To specify a persistent
instancevariable for
> > >> access
> > >> >> > > by the
> > >> >> > > persistence provider runtime, that instance variable
must be
> > >> >> > > desig-nated
> > >> >> > > Access(FIELD).</quote>*
> > >> >> > >
> > >> >> > >
> > >> >> > > I can see a few different ways to read that:
> > >> >> > >
> > >> >> > > 1) @Access can be placed on the attribute to define
both where
> > >> >> > > to
> > >> look
> > >> >> > > for
> > >> >> > > mapping annotations and the runtime access strategy
for a
> > >> >> > > given
> > >> >> > > attribute.
> > >> >> > > Here, we'd do:
> > >> >> > >
> > >> >> > > @Entity
> > >> >> > > @Access(AccessType.PROPERTY)
> > >> >> > > public class Course3 {
> > >> >> > > @Id
> > >> >> > > @GeneratedValue
> > >> >> > > @Access(AccessType.FIELD)
> > >> >> > > private long id;
> > >> >> > > ...
> > >> >> > >
> > >> >> > > public long getId() {
> > >> >> > > return id;
> > >> >> > > }
> > >> >> > > ...
> > >> >> > > }
> > >> >> > >
> > >> >> > > 2) @Access can be placed on the attribute to define
the
> > >> >> > > runtime
> > >> access
> > >> >> > > strategy for a given attribute, but the
class/hierarchy
> > >> >> > > AccessType
> > >> >> > > controls
> > >> >> > > where to look for mapping annotations. This would
lead to:
> > >> >> > >
> > >> >> > > @Entity
> > >> >> > > @Access(AccessType.PROPERTY)
> > >> >> > > public class Course3 {
> > >> >> > > @Access(AccessType.FIELD)
> > >> >> > > private long id;
> > >> >> > > ...
> > >> >> > >
> > >> >> > > @Id
> > >> >> > > @GeneratedValue
> > >> >> > > public long getId() {
> > >> >> > > return id;
> > >> >> > > }
> > >> >> > > ...
> > >> >> > > }
> > >> >> > >
> > >> >> > > The test seems to illustrate that our legacy code
made yet a
> > >> >> > > 3rd
> > >> >> > > reading of
> > >> >> > > this passage such that @Access is still considered a
"mapping
> > >> >> > > annotation"
> > >> >> > > even though that seems to directly contradict
"To specify a
> > >> persistent
> > >> >> > > instance
> > >> >> > > variable for access by the persistence provider
runtime, that
> > >> instance
> > >> >> > > variable must be desig-
> > >> >> > > nated Access(FIELD)."
> > >> >> > >
> > >> >> > >
> > >> >> > > Is there some other passage I am missing that bears
on what to
> > >> >> > > do
> > >> >> > > here?
> > >> >> > > How do y'all feel about that passage and its
implications on
> > >> >> > > this
> > >> >> > > test
> > >> >> > > mapping?
> > >> >> > > _______________________________________________
> > >> >> > > hibernate-dev mailing list
> > >> >> > > hibernate-dev(a)lists.jboss.org
> > >> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >> > _______________________________________________
> > >> >> > hibernate-dev mailing list
> > >> >> > hibernate-dev(a)lists.jboss.org
> > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >
> > >> >
> > >>
> > >
> > >
2:46 p.m.
All I can do is quote myself again ;)
If @Access *at the attribute level* is ultimately *just* indicating how to
extract/inject then I think @Access(FIELD) on the getter does make sense.
On Wed, Mar 26, 2014 at 1:42 PM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
On 26 March 2014 18:37, Steve Ebersole <steve(a)hibernate.org>
wrote:
> My point is that I do not find annotating a getter method with
> @Access(FIELD) to be inherently common sense. It really boils down to
the
> purpose/intent of @Access. If @Access *at the attribute level* is
> ultimately *just* indicating how to extract/inject then I think
> @Access(FIELD) on the getter does make sense. If @Access *at the
attribute
> level* also directs where to look for annotations (consistent with
@Access
> at class/hierarchy-level) then I think @AccessFile needs to be on the
field
> along with the other annotations, assuming we stay with non-mixed
placement
> for an attribute.
Here a use case: as convention the team likes to put all annotations
on getters, but then for some specific reason a field needs to be
configured to have the ORM to use field access.
Seems fair enough?
Sanne
>
> So let's decide that first. Since the spec does not say clearly one way
or
> the other, I guess we have some leeway here.
>
> https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and
> @IdSetter) plays in here as well.
>
>
>
> On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard <
emmanuel(a)hibernate.org>
> wrote:
>>
>> My take on the spec as always been that I'd rather follow the intent,
>> the common sense above the letter. Likewise, I favored user experience
>> over spec strict adherence.
>> I did clash numerous time with the TCK in these targets but I still
>> prefer that over just doing something stupid but spec to the letter.
>> (this is general and not specific to that case).
>>
>> Anyway so my take is pretty much as it was when I first implemented
>> @AccessType even if it steps over the spec at the margin.
>> BTW I'm also happy if we all decide I made a usability mistake that
should
>> be fixed.
>>
>> Emmanuel
>>
>> On Wed 2014-03-26 11:14, Steve Ebersole wrote:
>> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole
>> > <steve(a)hibernate.org>wrote:
>> >
>> > > It does violate the spec though, that's the problem:
>> > >
>> >
>> > Well it *could* be read to violate the spec. That's inherently the
>> > problem
>> > with specs that use unclear wording; they can be read and argued
>> > multiple
>> > ways.
>> >
>> >
>> >
>> > >
>> > > "... It is not permitted to specify a field as Access(PROPERTY)
or a
>> > > property as Access(FIELD)..."
>> > >
>> > > which imo is exactly what this is doing (specifying a property as
>> > > FIELD):
>> > >
>> > > @Id
>> > > @GeneratedValue
>> > > @Access(AccessType.FIELD)
>> > > public long getId() {
>> > > return id;
>> > > }
>> > >
>> > >
>> > >
>> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero
>> > > <sanne(a)hibernate.org>wrote:
>> > >
>> > >> I do of course agree that people should use a single strategy and
>> > >> stick to it, so I agree with your reading about what the
"general
>> > >> expectation" is.
>> > >>
>> > >> But the original test represents a quite naturally looking
example
>> > >> and
>> > >> it's hard to justify why that should be considered illegal;
I'd
>> > >> probably be more inclined in making user's life easier than
try to
>> > >> lecture them about how a proper mapping should look like.
>> > >>
>> > >> Ignoring any annotation leads to waste of time and debugging
>> > >> frustration, so rather than silently discarding a mis-positioned
>> > >> annotation I'd prefer a fail-fast approach; that said I think
just
>> > >> applying them all - as long as there are no obvious conflicting
>> > >> annotations - would be even more user friendly and doesn't
seem to
>> > >> violate any specific wording of the spec.
>> > >>
>> > >> Sanne
>> > >>
>> > >>
>> > >> On 26 March 2014 13:57, Steve Ebersole
<steve(a)hibernate.org>
wrote:
>> > >> > Again from the spec (still discussing class-level
Access(PROPERTY))
>> > >> > :
>> > >> "The
>> > >> > behavior is undefined if mapping annotations are placed on
any
>> > >> > instance
>> > >> > variables defined by the class for which Access(FIELD) is
not
>> > >> specified".
>> > >> >
>> > >> > Which to me implies that the expectation for switching
access
for a
>> > >> > particular field within such a class is to annotate the
*field*
>> > >> > with
>> > >> > Access(FIELD).
>> > >> >
>> > >> > Also the footnote to this sections seems very relevant:
>> > >> >
>> > >> > "[8] ... It is not permitted to specify a field as
Access(PROPERTY)
>> > >> > or a
>> > >> > property as Access(FIELD)..."
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
>> > >> emmanuel(a)hibernate.org>
>> > >> > wrote:
>> > >> >>
>> > >> >> My reading at the time and what I did find more intuitive
is
what
>> > >> >> the
>> > >> >> test represents.
>> > >> >>
>> > >> >> Entity level @AccessType expresses where the annotations
should
>> > >> >> be. Otherwise the position of @Id is used to find the
access
type
>> > >> >> to
>> > >> >> consider annotation wise.
>> > >> >>
>> > >> >> If for a few attributes I wish to use the alternative
property
>> > >> >> access,
>> > >> I
>> > >> >> can add @AccessType next to the other annotations but
expressing
>> > >> >> that
>> > >> >> the actual property value access is based on the
alternative
>> > >> >> access.
>> > >> >> That way, all annotations are in the same place.
>> > >> >>
>> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
>> > >> >> > As a user I would not expect the @Access annotation
to be
>> > >> >> > treated as
>> > >> a
>> > >> >> > special case by the framework in terms of when an
annotation
is
>> > >> >> > ignored, as for example that I can put this on
either
properties
>> > >> >> > or
>> > >> >> > fields, and it would not be ignored, while other
annotations
>> > >> >> > could be
>> > >> >> > ignored depending on the position.
>> > >> >> >
>> > >> >> > Also I highly doubt that there is a practical use
case to
>> > >> >> > "comment" a
>> > >> >> > mapping annotation by moving it to the wrong
position (say I
>> > >> >> > move a
>> > >> >> > @GeneratedValue from a field to a property when
using FIELD
>> > >> >> > access):
>> > >> >> > that would be extremely confusing to maintain.
>> > >> >> >
>> > >> >> > The spec's wording states "When
Access(PROPERTY) is applied to
>> > >> >> > an
>> > >> >> > [...] mapping annotations **may** be placed on
.."
>> > >> >> > I'd stress that it doesn' t say
"must" but "may", and also
>> > >> >> > doesn't
>> > >> >> > seem to strictly ban the opposite.
>> > >> >> >
>> > >> >> > As a user if I put a mapping annotation anywhere I
expect it
to
>> > >> >> > be
>> > >> >> > respected, so I would expect the framework to work
on the
union
>> > >> >> > of
>> > >> the
>> > >> >> > possible positions, and probably even to throw an
exception on
>> > >> >> > conflicting options. The @Access property would then
only be
>> > >> >> > used to
>> > >> >> > state which access strategy should be used (and a
nice effect
is
>> > >> >> > tha
>> > >> >> > the name becomes particularly self-explanatory
too).
>> > >> >> >
>> > >> >> > Also there are many types of possible contradictions
in the
>> > >> >> > mapping
>> > >> >> > options:
>> > >> >> >
>> > >> >> > public class Course {
>> > >> >> > @Id @GeneratedValue(strategy=TABLE)
>> > >> >> > private long id;
>> > >> >> > ...
>> > >> >> >
>> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
>> > >> >> > public long getId() {
>> > >> >> > return id;
>> > >> >> > }
>> > >> >> >
>> > >> >> > Or you could have a stronger conflict which
isn't solvable via
>> > >> >> > AccesType "rules" either:
>> > >> >> >
>> > >> >> > public class Course {
>> > >> >> > @Id @GeneratedValue(strategy=TABLE)
>> > >> >> > @Access(AccessType.FIELD)
>> > >> >> > private long id;
>> > >> >> > ...
>> > >> >> >
>> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
>> > >> >> > @Access(AccessType.PROPERTY)
>> > >> >> > public long getId() {
>> > >> >> > return id;
>> > >> >> > }
>> > >> >> >
>> > >> >> > This last example is the reason why I think you
should always
>> > >> >> > consistently look at both to collect mapping
options, and
>> > >> >> > possibly
>> > >> >> > throw runtime exceptions.
>> > >> >> >
>> > >> >> > Sanne
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org>
>> > >> >> > wrote:
>> > >> >> > > >From the test
>> > >> >> > >
>> > >> >> > >
>> > >>
>> > >>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
>> > >> >> > > we have the following:
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > @Entity
>> > >> >> > > @Access(AccessType.PROPERTY)
>> > >> >> > > public class Course3 {
>> > >> >> > > private long id;
>> > >> >> > > ...
>> > >> >> > >
>> > >> >> > > @Id
>> > >> >> > > @GeneratedValue
>> > >> >> > > @Access(AccessType.FIELD)
>> > >> >> > > public long getId() {
>> > >> >> > > return id;
>> > >> >> > > }
>> > >> >> > > ...
>> > >> >> > > }
>> > >> >> > >
>> > >> >> > > The test asserts that this is a valid mapping.
Granted that
>> > >> >> > > the
>> > >> spec
>> > >> >> > > is
>> > >> >> > > very unclear here, so I might be missing
something. The
>> > >> >> > > pertinent
>> > >> >> > > spec
>> > >> >> > > section here states:
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > *<quote>When Access(PROPERTY) is applied
to an entity class,
>> > >> >> > > mapped
>> > >> >> > > superclass, or embeddableclass, mapping
annotations may be
>> > >> >> > > placed
>> > >> on
>> > >> >> > > the
>> > >> >> > > properties of that class, and the
persistenceprovider
runtime
>> > >> accesses
>> > >> >> > > persistent state via the properties defined by
that class.
All
>> > >> >> > > proper-ties
>> > >> >> > > that are not annotated with the Transient
annotation are
>> > >> persistent.
>> > >> >> > > WhenAccess(PROPERTY) is applied to such a
class, it is
>> > >> >> > > possible to
>> > >> >> > > selectively designate indi-vidual attributes
within the
class
>> > >> >> > > for
>> > >> >> > > instance
>> > >> >> > > variable access. To specify a persistent
instancevariable
for
>> > >> access
>> > >> >> > > by the
>> > >> >> > > persistence provider runtime, that instance
variable must be
>> > >> >> > > desig-nated
>> > >> >> > > Access(FIELD).</quote>*
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > I can see a few different ways to read that:
>> > >> >> > >
>> > >> >> > > 1) @Access can be placed on the attribute to
define both
where
>> > >> >> > > to
>> > >> look
>> > >> >> > > for
>> > >> >> > > mapping annotations and the runtime access
strategy for a
>> > >> >> > > given
>> > >> >> > > attribute.
>> > >> >> > > Here, we'd do:
>> > >> >> > >
>> > >> >> > > @Entity
>> > >> >> > > @Access(AccessType.PROPERTY)
>> > >> >> > > public class Course3 {
>> > >> >> > > @Id
>> > >> >> > > @GeneratedValue
>> > >> >> > > @Access(AccessType.FIELD)
>> > >> >> > > private long id;
>> > >> >> > > ...
>> > >> >> > >
>> > >> >> > > public long getId() {
>> > >> >> > > return id;
>> > >> >> > > }
>> > >> >> > > ...
>> > >> >> > > }
>> > >> >> > >
>> > >> >> > > 2) @Access can be placed on the attribute to
define the
>> > >> >> > > runtime
>> > >> access
>> > >> >> > > strategy for a given attribute, but the
class/hierarchy
>> > >> >> > > AccessType
>> > >> >> > > controls
>> > >> >> > > where to look for mapping annotations. This
would lead to:
>> > >> >> > >
>> > >> >> > > @Entity
>> > >> >> > > @Access(AccessType.PROPERTY)
>> > >> >> > > public class Course3 {
>> > >> >> > > @Access(AccessType.FIELD)
>> > >> >> > > private long id;
>> > >> >> > > ...
>> > >> >> > >
>> > >> >> > > @Id
>> > >> >> > > @GeneratedValue
>> > >> >> > > public long getId() {
>> > >> >> > > return id;
>> > >> >> > > }
>> > >> >> > > ...
>> > >> >> > > }
>> > >> >> > >
>> > >> >> > > The test seems to illustrate that our legacy
code made yet a
>> > >> >> > > 3rd
>> > >> >> > > reading of
>> > >> >> > > this passage such that @Access is still
considered a
"mapping
>> > >> >> > > annotation"
>> > >> >> > > even though that seems to directly contradict
"To specify a
>> > >> persistent
>> > >> >> > > instance
>> > >> >> > > variable for access by the persistence provider
runtime,
that
>> > >> instance
>> > >> >> > > variable must be desig-
>> > >> >> > > nated Access(FIELD)."
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > Is there some other passage I am missing that
bears on what
to
>> > >> >> > > do
>> > >> >> > > here?
>> > >> >> > > How do y'all feel about that passage and
its implications
on
>> > >> >> > > this
>> > >> >> > > test
>> > >> >> > > mapping?
>> > >> >> > >
_______________________________________________
>> > >> >> > > hibernate-dev mailing list
>> > >> >> > > hibernate-dev(a)lists.jboss.org
>> > >> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > _______________________________________________
>> > >> >> > hibernate-dev mailing list
>> > >> >> > hibernate-dev(a)lists.jboss.org
>> > >> >> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>
>
3:01 p.m.
On 26 Jan 2014, at 05:13, Steve Ebersole <steve(a)hibernate.org> wrote:
> From the test
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
we have the following:
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
private long id;
...
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
...
}
The test asserts that this is a valid mapping. Granted that the spec is
very unclear here, so I might be missing something. The pertinent spec
section here states:
For what its worth, I think the mapping is not valid (according to my interpretation of
the spec).
@Access(AccessType.FIELD) would need to be specified on the field to take effect. Whether
this mapping
is valid in a sense that is ignores @Access(AccessType.FIELD) is a different question.
However, referring to your test, afaics the test and class in question (Course3) uses
@org.hibernate.annotations.AccessType("field”) which is a different thing altogether.
Here we are dealing
with the now deprecated org.hibernate.annotations.AccessType annotation. AFAIK, this
annotation used
to be placed together with other mapping annotations.
So what do we want to discuss here really?
—Hardy
3:05 p.m.
Hardy, not sure where you are looking... But in master Course3 DOES NOT
use @org.hibernate.annotations.AccessType...
On Wed, Mar 26, 2014 at 2:01 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 26 Jan 2014, at 05:13, Steve Ebersole <steve(a)hibernate.org> wrote:
>> From the test
>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> we have the following:
>
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> private long id;
> ...
>
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> public long getId() {
> return id;
> }
> ...
> }
>
> The test asserts that this is a valid mapping. Granted that the spec is
> very unclear here, so I might be missing something. The pertinent spec
> section here states:
For what its worth, I think the mapping is not valid (according to my
interpretation of the spec).
@Access(AccessType.FIELD) would need to be specified on the field to take
effect. Whether this mapping
is valid in a sense that is ignores @Access(AccessType.FIELD) is a
different question.
However, referring to your test, afaics the test and class in question
(Course3) uses
@org.hibernate.annotations.AccessType("field") which is a different thing
altogether. Here we are dealing
with the now deprecated org.hibernate.annotations.AccessType annotation.
AFAIK, this annotation used
to be placed together with other mapping annotations.
So what do we want to discuss here really?
--Hardy
3:08 p.m.
To be clear Sanne, I am not arguing with your point or point-of-view.
I am just saying that we should have a concise, consistent answer as to
what AccessType means. We do not have that today.
And just to point out, allowing @Access(FIELD) on a getter makes it operate
inconsistently from @Acess(FIELD) on a class. Again, that does not make it
wrong, but we need to understand that inconsistency and be able to justify
it.
On Wed, Mar 26, 2014 at 1:42 PM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
On 26 March 2014 18:37, Steve Ebersole <steve(a)hibernate.org>
wrote:
> My point is that I do not find annotating a getter method with
> @Access(FIELD) to be inherently common sense. It really boils down to
the
> purpose/intent of @Access. If @Access *at the attribute level* is
> ultimately *just* indicating how to extract/inject then I think
> @Access(FIELD) on the getter does make sense. If @Access *at the
attribute
> level* also directs where to look for annotations (consistent with
@Access
> at class/hierarchy-level) then I think @AccessFile needs to be on the
field
> along with the other annotations, assuming we stay with non-mixed
placement
> for an attribute.
Here a use case: as convention the team likes to put all annotations
on getters, but then for some specific reason a field needs to be
configured to have the ORM to use field access.
Seems fair enough?
Sanne
>
> So let's decide that first. Since the spec does not say clearly one way
or
> the other, I guess we have some leeway here.
>
> https://hibernate.atlassian.net/browse/HHH-9085 (Introduce @IdGetter and
> @IdSetter) plays in here as well.
>
>
>
> On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard <
emmanuel(a)hibernate.org>
> wrote:
>>
>> My take on the spec as always been that I'd rather follow the intent,
>> the common sense above the letter. Likewise, I favored user experience
>> over spec strict adherence.
>> I did clash numerous time with the TCK in these targets but I still
>> prefer that over just doing something stupid but spec to the letter.
>> (this is general and not specific to that case).
>>
>> Anyway so my take is pretty much as it was when I first implemented
>> @AccessType even if it steps over the spec at the margin.
>> BTW I'm also happy if we all decide I made a usability mistake that
should
>> be fixed.
>>
>> Emmanuel
>>
>> On Wed 2014-03-26 11:14, Steve Ebersole wrote:
>> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole
>> > <steve(a)hibernate.org>wrote:
>> >
>> > > It does violate the spec though, that's the problem:
>> > >
>> >
>> > Well it *could* be read to violate the spec. That's inherently the
>> > problem
>> > with specs that use unclear wording; they can be read and argued
>> > multiple
>> > ways.
>> >
>> >
>> >
>> > >
>> > > "... It is not permitted to specify a field as Access(PROPERTY)
or a
>> > > property as Access(FIELD)..."
>> > >
>> > > which imo is exactly what this is doing (specifying a property as
>> > > FIELD):
>> > >
>> > > @Id
>> > > @GeneratedValue
>> > > @Access(AccessType.FIELD)
>> > > public long getId() {
>> > > return id;
>> > > }
>> > >
>> > >
>> > >
>> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero
>> > > <sanne(a)hibernate.org>wrote:
>> > >
>> > >> I do of course agree that people should use a single strategy and
>> > >> stick to it, so I agree with your reading about what the
"general
>> > >> expectation" is.
>> > >>
>> > >> But the original test represents a quite naturally looking
example
>> > >> and
>> > >> it's hard to justify why that should be considered illegal;
I'd
>> > >> probably be more inclined in making user's life easier than
try to
>> > >> lecture them about how a proper mapping should look like.
>> > >>
>> > >> Ignoring any annotation leads to waste of time and debugging
>> > >> frustration, so rather than silently discarding a mis-positioned
>> > >> annotation I'd prefer a fail-fast approach; that said I think
just
>> > >> applying them all - as long as there are no obvious conflicting
>> > >> annotations - would be even more user friendly and doesn't
seem to
>> > >> violate any specific wording of the spec.
>> > >>
>> > >> Sanne
>> > >>
>> > >>
>> > >> On 26 March 2014 13:57, Steve Ebersole
<steve(a)hibernate.org>
wrote:
>> > >> > Again from the spec (still discussing class-level
Access(PROPERTY))
>> > >> > :
>> > >> "The
>> > >> > behavior is undefined if mapping annotations are placed on
any
>> > >> > instance
>> > >> > variables defined by the class for which Access(FIELD) is
not
>> > >> specified".
>> > >> >
>> > >> > Which to me implies that the expectation for switching
access
for a
>> > >> > particular field within such a class is to annotate the
*field*
>> > >> > with
>> > >> > Access(FIELD).
>> > >> >
>> > >> > Also the footnote to this sections seems very relevant:
>> > >> >
>> > >> > "[8] ... It is not permitted to specify a field as
Access(PROPERTY)
>> > >> > or a
>> > >> > property as Access(FIELD)..."
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
>> > >> emmanuel(a)hibernate.org>
>> > >> > wrote:
>> > >> >>
>> > >> >> My reading at the time and what I did find more intuitive
is
what
>> > >> >> the
>> > >> >> test represents.
>> > >> >>
>> > >> >> Entity level @AccessType expresses where the annotations
should
>> > >> >> be. Otherwise the position of @Id is used to find the
access
type
>> > >> >> to
>> > >> >> consider annotation wise.
>> > >> >>
>> > >> >> If for a few attributes I wish to use the alternative
property
>> > >> >> access,
>> > >> I
>> > >> >> can add @AccessType next to the other annotations but
expressing
>> > >> >> that
>> > >> >> the actual property value access is based on the
alternative
>> > >> >> access.
>> > >> >> That way, all annotations are in the same place.
>> > >> >>
>> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
>> > >> >> > As a user I would not expect the @Access annotation
to be
>> > >> >> > treated as
>> > >> a
>> > >> >> > special case by the framework in terms of when an
annotation
is
>> > >> >> > ignored, as for example that I can put this on
either
properties
>> > >> >> > or
>> > >> >> > fields, and it would not be ignored, while other
annotations
>> > >> >> > could be
>> > >> >> > ignored depending on the position.
>> > >> >> >
>> > >> >> > Also I highly doubt that there is a practical use
case to
>> > >> >> > "comment" a
>> > >> >> > mapping annotation by moving it to the wrong
position (say I
>> > >> >> > move a
>> > >> >> > @GeneratedValue from a field to a property when
using FIELD
>> > >> >> > access):
>> > >> >> > that would be extremely confusing to maintain.
>> > >> >> >
>> > >> >> > The spec's wording states "When
Access(PROPERTY) is applied to
>> > >> >> > an
>> > >> >> > [...] mapping annotations **may** be placed on
.."
>> > >> >> > I'd stress that it doesn' t say
"must" but "may", and also
>> > >> >> > doesn't
>> > >> >> > seem to strictly ban the opposite.
>> > >> >> >
>> > >> >> > As a user if I put a mapping annotation anywhere I
expect it
to
>> > >> >> > be
>> > >> >> > respected, so I would expect the framework to work
on the
union
>> > >> >> > of
>> > >> the
>> > >> >> > possible positions, and probably even to throw an
exception on
>> > >> >> > conflicting options. The @Access property would then
only be
>> > >> >> > used to
>> > >> >> > state which access strategy should be used (and a
nice effect
is
>> > >> >> > tha
>> > >> >> > the name becomes particularly self-explanatory
too).
>> > >> >> >
>> > >> >> > Also there are many types of possible contradictions
in the
>> > >> >> > mapping
>> > >> >> > options:
>> > >> >> >
>> > >> >> > public class Course {
>> > >> >> > @Id @GeneratedValue(strategy=TABLE)
>> > >> >> > private long id;
>> > >> >> > ...
>> > >> >> >
>> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
>> > >> >> > public long getId() {
>> > >> >> > return id;
>> > >> >> > }
>> > >> >> >
>> > >> >> > Or you could have a stronger conflict which
isn't solvable via
>> > >> >> > AccesType "rules" either:
>> > >> >> >
>> > >> >> > public class Course {
>> > >> >> > @Id @GeneratedValue(strategy=TABLE)
>> > >> >> > @Access(AccessType.FIELD)
>> > >> >> > private long id;
>> > >> >> > ...
>> > >> >> >
>> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
>> > >> >> > @Access(AccessType.PROPERTY)
>> > >> >> > public long getId() {
>> > >> >> > return id;
>> > >> >> > }
>> > >> >> >
>> > >> >> > This last example is the reason why I think you
should always
>> > >> >> > consistently look at both to collect mapping
options, and
>> > >> >> > possibly
>> > >> >> > throw runtime exceptions.
>> > >> >> >
>> > >> >> > Sanne
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org>
>> > >> >> > wrote:
>> > >> >> > > >From the test
>> > >> >> > >
>> > >> >> > >
>> > >>
>> > >>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
>> > >> >> > > we have the following:
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > @Entity
>> > >> >> > > @Access(AccessType.PROPERTY)
>> > >> >> > > public class Course3 {
>> > >> >> > > private long id;
>> > >> >> > > ...
>> > >> >> > >
>> > >> >> > > @Id
>> > >> >> > > @GeneratedValue
>> > >> >> > > @Access(AccessType.FIELD)
>> > >> >> > > public long getId() {
>> > >> >> > > return id;
>> > >> >> > > }
>> > >> >> > > ...
>> > >> >> > > }
>> > >> >> > >
>> > >> >> > > The test asserts that this is a valid mapping.
Granted that
>> > >> >> > > the
>> > >> spec
>> > >> >> > > is
>> > >> >> > > very unclear here, so I might be missing
something. The
>> > >> >> > > pertinent
>> > >> >> > > spec
>> > >> >> > > section here states:
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > *<quote>When Access(PROPERTY) is applied
to an entity class,
>> > >> >> > > mapped
>> > >> >> > > superclass, or embeddableclass, mapping
annotations may be
>> > >> >> > > placed
>> > >> on
>> > >> >> > > the
>> > >> >> > > properties of that class, and the
persistenceprovider
runtime
>> > >> accesses
>> > >> >> > > persistent state via the properties defined by
that class.
All
>> > >> >> > > proper-ties
>> > >> >> > > that are not annotated with the Transient
annotation are
>> > >> persistent.
>> > >> >> > > WhenAccess(PROPERTY) is applied to such a
class, it is
>> > >> >> > > possible to
>> > >> >> > > selectively designate indi-vidual attributes
within the
class
>> > >> >> > > for
>> > >> >> > > instance
>> > >> >> > > variable access. To specify a persistent
instancevariable
for
>> > >> access
>> > >> >> > > by the
>> > >> >> > > persistence provider runtime, that instance
variable must be
>> > >> >> > > desig-nated
>> > >> >> > > Access(FIELD).</quote>*
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > I can see a few different ways to read that:
>> > >> >> > >
>> > >> >> > > 1) @Access can be placed on the attribute to
define both
where
>> > >> >> > > to
>> > >> look
>> > >> >> > > for
>> > >> >> > > mapping annotations and the runtime access
strategy for a
>> > >> >> > > given
>> > >> >> > > attribute.
>> > >> >> > > Here, we'd do:
>> > >> >> > >
>> > >> >> > > @Entity
>> > >> >> > > @Access(AccessType.PROPERTY)
>> > >> >> > > public class Course3 {
>> > >> >> > > @Id
>> > >> >> > > @GeneratedValue
>> > >> >> > > @Access(AccessType.FIELD)
>> > >> >> > > private long id;
>> > >> >> > > ...
>> > >> >> > >
>> > >> >> > > public long getId() {
>> > >> >> > > return id;
>> > >> >> > > }
>> > >> >> > > ...
>> > >> >> > > }
>> > >> >> > >
>> > >> >> > > 2) @Access can be placed on the attribute to
define the
>> > >> >> > > runtime
>> > >> access
>> > >> >> > > strategy for a given attribute, but the
class/hierarchy
>> > >> >> > > AccessType
>> > >> >> > > controls
>> > >> >> > > where to look for mapping annotations. This
would lead to:
>> > >> >> > >
>> > >> >> > > @Entity
>> > >> >> > > @Access(AccessType.PROPERTY)
>> > >> >> > > public class Course3 {
>> > >> >> > > @Access(AccessType.FIELD)
>> > >> >> > > private long id;
>> > >> >> > > ...
>> > >> >> > >
>> > >> >> > > @Id
>> > >> >> > > @GeneratedValue
>> > >> >> > > public long getId() {
>> > >> >> > > return id;
>> > >> >> > > }
>> > >> >> > > ...
>> > >> >> > > }
>> > >> >> > >
>> > >> >> > > The test seems to illustrate that our legacy
code made yet a
>> > >> >> > > 3rd
>> > >> >> > > reading of
>> > >> >> > > this passage such that @Access is still
considered a
"mapping
>> > >> >> > > annotation"
>> > >> >> > > even though that seems to directly contradict
"To specify a
>> > >> persistent
>> > >> >> > > instance
>> > >> >> > > variable for access by the persistence provider
runtime,
that
>> > >> instance
>> > >> >> > > variable must be desig-
>> > >> >> > > nated Access(FIELD)."
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > Is there some other passage I am missing that
bears on what
to
>> > >> >> > > do
>> > >> >> > > here?
>> > >> >> > > How do y'all feel about that passage and
its implications
on
>> > >> >> > > this
>> > >> >> > > test
>> > >> >> > > mapping?
>> > >> >> > >
_______________________________________________
>> > >> >> > > hibernate-dev mailing list
>> > >> >> > > hibernate-dev(a)lists.jboss.org
>> > >> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > _______________________________________________
>> > >> >> > hibernate-dev mailing list
>> > >> >> > hibernate-dev(a)lists.jboss.org
>> > >> >> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>
>
3:14 p.m.
Hi,
you are right, the current code used @Access(AccessType.FIELD) -
https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/sr...
However, this is wrong. I actually looked first in my local checkout which is a bit
outdated, but there @org.hibernate.annotations.AccessType is still used.
Judging by the test name this was clearly the intent of the test as well.
It seems the test got changed a month ago in order to fix test failures -
https://github.com/hibernate/hibernate-orm/commit/ff12d5c#diff-40
In this case the change was wrong. I guess the idea was to get rid of the deprecated
annotation use, but the whole test should have been deleted.
—Hardy
On 26 Jan 2014, at 20:05, Steve Ebersole <steve(a)hibernate.org> wrote:
Hardy, not sure where you are looking... But in master Course3 DOES
NOT use @org.hibernate.annotations.AccessType...
On Wed, Mar 26, 2014 at 2:01 PM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 26 Jan 2014, at 05:13, Steve Ebersole <steve(a)hibernate.org> wrote:
>> From the test
>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> we have the following:
>
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> private long id;
> ...
>
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> public long getId() {
> return id;
> }
> ...
> }
>
> The test asserts that this is a valid mapping. Granted that the spec is
> very unclear here, so I might be missing something. The pertinent spec
> section here states:
For what its worth, I think the mapping is not valid (according to my interpretation of
the spec).
@Access(AccessType.FIELD) would need to be specified on the field to take effect. Whether
this mapping
is valid in a sense that is ignores @Access(AccessType.FIELD) is a different question.
However, referring to your test, afaics the test and class in question (Course3) uses
@org.hibernate.annotations.AccessType("field”) which is a different thing
altogether. Here we are dealing
with the now deprecated org.hibernate.annotations.AccessType annotation. AFAIK, this
annotation used
to be placed together with other mapping annotations.
So what do we want to discuss here really?
—Hardy
3:14 p.m.
So the spec does specifically say "It is not permitted to specify a field
as Access(PROPERTY) or a property as Access(FIELD)". I understanding
making usability choices when the spec is unclear. Do you think there is
non-clarity in that quote though?
Even if you say making usability choices when the spec is very clear, but
"wrong"... again I can live with that. But we need to be clear about that.
On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org>wrote:
My take on the spec as always been that I'd rather follow the
intent,
the common sense above the letter. Likewise, I favored user experience
over spec strict adherence.
I did clash numerous time with the TCK in these targets but I still
prefer that over just doing something stupid but spec to the letter.
(this is general and not specific to that case).
Anyway so my take is pretty much as it was when I first implemented
@AccessType even if it steps over the spec at the margin.
BTW I'm also happy if we all decide I made a usability mistake that should
be fixed.
Emmanuel
On Wed 2014-03-26 11:14, Steve Ebersole wrote:
> On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole <steve(a)hibernate.org
>wrote:
>
> > It does violate the spec though, that's the problem:
> >
>
> Well it *could* be read to violate the spec. That's inherently the
problem
> with specs that use unclear wording; they can be read and argued multiple
> ways.
>
>
>
> >
> > "... It is not permitted to specify a field as Access(PROPERTY) or a
> > property as Access(FIELD)..."
> >
> > which imo is exactly what this is doing (specifying a property as
FIELD):
> >
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > public long getId() {
> > return id;
> > }
> >
> >
> >
> > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero <sanne(a)hibernate.org
>wrote:
> >
> >> I do of course agree that people should use a single strategy and
> >> stick to it, so I agree with your reading about what the "general
> >> expectation" is.
> >>
> >> But the original test represents a quite naturally looking example and
> >> it's hard to justify why that should be considered illegal; I'd
> >> probably be more inclined in making user's life easier than try to
> >> lecture them about how a proper mapping should look like.
> >>
> >> Ignoring any annotation leads to waste of time and debugging
> >> frustration, so rather than silently discarding a mis-positioned
> >> annotation I'd prefer a fail-fast approach; that said I think just
> >> applying them all - as long as there are no obvious conflicting
> >> annotations - would be even more user friendly and doesn't seem to
> >> violate any specific wording of the spec.
> >>
> >> Sanne
> >>
> >>
> >> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
> >> > Again from the spec (still discussing class-level Access(PROPERTY))
:
> >> "The
> >> > behavior is undefined if mapping annotations are placed on any
instance
> >> > variables defined by the class for which Access(FIELD) is not
> >> specified".
> >> >
> >> > Which to me implies that the expectation for switching access for a
> >> > particular field within such a class is to annotate the *field* with
> >> > Access(FIELD).
> >> >
> >> > Also the footnote to this sections seems very relevant:
> >> >
> >> > "[8] ... It is not permitted to specify a field as
Access(PROPERTY)
or a
> >> > property as Access(FIELD)..."
> >> >
> >> >
> >> >
> >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
> >> emmanuel(a)hibernate.org>
> >> > wrote:
> >> >>
> >> >> My reading at the time and what I did find more intuitive is what
the
> >> >> test represents.
> >> >>
> >> >> Entity level @AccessType expresses where the annotations should
> >> >> be. Otherwise the position of @Id is used to find the access type
to
> >> >> consider annotation wise.
> >> >>
> >> >> If for a few attributes I wish to use the alternative property
access,
> >> I
> >> >> can add @AccessType next to the other annotations but expressing
that
> >> >> the actual property value access is based on the alternative
access.
> >> >> That way, all annotations are in the same place.
> >> >>
> >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> >> >> > As a user I would not expect the @Access annotation to be
treated as
> >> a
> >> >> > special case by the framework in terms of when an annotation
is
> >> >> > ignored, as for example that I can put this on either
properties
or
> >> >> > fields, and it would not be ignored, while other annotations
could be
> >> >> > ignored depending on the position.
> >> >> >
> >> >> > Also I highly doubt that there is a practical use case to
"comment" a
> >> >> > mapping annotation by moving it to the wrong position (say I
move a
> >> >> > @GeneratedValue from a field to a property when using FIELD
access):
> >> >> > that would be extremely confusing to maintain.
> >> >> >
> >> >> > The spec's wording states "When Access(PROPERTY) is
applied to an
> >> >> > [...] mapping annotations **may** be placed on .."
> >> >> > I'd stress that it doesn' t say "must" but
"may", and also
doesn't
> >> >> > seem to strictly ban the opposite.
> >> >> >
> >> >> > As a user if I put a mapping annotation anywhere I expect it
to
be
> >> >> > respected, so I would expect the framework to work on the
union
of
> >> the
> >> >> > possible positions, and probably even to throw an exception
on
> >> >> > conflicting options. The @Access property would then only be
used to
> >> >> > state which access strategy should be used (and a nice effect
is
tha
> >> >> > the name becomes particularly self-explanatory too).
> >> >> >
> >> >> > Also there are many types of possible contradictions in the
mapping
> >> >> > options:
> >> >> >
> >> >> > public class Course {
> >> >> > @Id @GeneratedValue(strategy=TABLE)
> >> >> > private long id;
> >> >> > ...
> >> >> >
> >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> >> > public long getId() {
> >> >> > return id;
> >> >> > }
> >> >> >
> >> >> > Or you could have a stronger conflict which isn't
solvable via
> >> >> > AccesType "rules" either:
> >> >> >
> >> >> > public class Course {
> >> >> > @Id @GeneratedValue(strategy=TABLE)
> >> >> > @Access(AccessType.FIELD)
> >> >> > private long id;
> >> >> > ...
> >> >> >
> >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> >> > @Access(AccessType.PROPERTY)
> >> >> > public long getId() {
> >> >> > return id;
> >> >> > }
> >> >> >
> >> >> > This last example is the reason why I think you should
always
> >> >> > consistently look at both to collect mapping options, and
possibly
> >> >> > throw runtime exceptions.
> >> >> >
> >> >> > Sanne
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org>
wrote:
> >> >> > > >From the test
> >> >> > >
> >> >> > >
> >>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> >> >> > > we have the following:
> >> >> > >
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > The test asserts that this is a valid mapping. Granted
that
the
> >> spec
> >> >> > > is
> >> >> > > very unclear here, so I might be missing something.
The
pertinent
> >> >> > > spec
> >> >> > > section here states:
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > *<quote>When Access(PROPERTY) is applied to an
entity class,
mapped
> >> >> > > superclass, or embeddableclass, mapping annotations may
be
placed
> >> on
> >> >> > > the
> >> >> > > properties of that class, and the persistenceprovider
runtime
> >> accesses
> >> >> > > persistent state via the properties defined by that
class. All
> >> >> > > proper-ties
> >> >> > > that are not annotated with the Transient annotation
are
> >> persistent.
> >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is
possible to
> >> >> > > selectively designate indi-vidual attributes within the
class
for
> >> >> > > instance
> >> >> > > variable access. To specify a persistent
instancevariable for
> >> access
> >> >> > > by the
> >> >> > > persistence provider runtime, that instance variable
must be
> >> >> > > desig-nated
> >> >> > > Access(FIELD).</quote>*
> >> >> > >
> >> >> > >
> >> >> > > I can see a few different ways to read that:
> >> >> > >
> >> >> > > 1) @Access can be placed on the attribute to define both
where
to
> >> look
> >> >> > > for
> >> >> > > mapping annotations and the runtime access strategy for
a given
> >> >> > > attribute.
> >> >> > > Here, we'd do:
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > 2) @Access can be placed on the attribute to define the
runtime
> >> access
> >> >> > > strategy for a given attribute, but the class/hierarchy
AccessType
> >> >> > > controls
> >> >> > > where to look for mapping annotations. This would lead
to:
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > The test seems to illustrate that our legacy code made
yet a
3rd
> >> >> > > reading of
> >> >> > > this passage such that @Access is still considered a
"mapping
> >> >> > > annotation"
> >> >> > > even though that seems to directly contradict "To
specify a
> >> persistent
> >> >> > > instance
> >> >> > > variable for access by the persistence provider runtime,
that
> >> instance
> >> >> > > variable must be desig-
> >> >> > > nated Access(FIELD)."
> >> >> > >
> >> >> > >
> >> >> > > Is there some other passage I am missing that bears on
what to
do
> >> >> > > here?
> >> >> > > How do y'all feel about that passage and its
implications on
this
> >> >> > > test
> >> >> > > mapping?
> >> >> > > _______________________________________________
> >> >> > > hibernate-dev mailing list
> >> >> > > hibernate-dev(a)lists.jboss.org
> >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev(a)lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >>
> >
> >
3:16 p.m.
Ok, but... its still a good spring board to discuss this topic which is
strangely unclear and murky in terms of what we do and do not support.
On Wed, Mar 26, 2014 at 2:14 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
Hi,
you are right, the current code used @Access(AccessType.FIELD) -
https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/sr...
However, this is wrong. I actually looked first in my local checkout which
is a bit outdated, but there @org.hibernate.annotations.AccessType is still
used.
Judging by the test name this was clearly the intent of the test as well.
It seems the test got changed a month ago in order to fix test failures -
https://github.com/hibernate/hibernate-orm/commit/ff12d5c#diff-40
In this case the change was wrong. I guess the idea was to get rid of the
deprecated annotation use, but the whole test should have been deleted.
--Hardy
On 26 Jan 2014, at 20:05, Steve Ebersole <steve(a)hibernate.org> wrote:
> Hardy, not sure where you are looking... But in master Course3 DOES NOT
use @org.hibernate.annotations.AccessType...
>
>
> On Wed, Mar 26, 2014 at 2:01 PM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
>
> On 26 Jan 2014, at 05:13, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> >> From the test
> >
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> > we have the following:
> >
> >
> > @Entity
> > @Access(AccessType.PROPERTY)
> > public class Course3 {
> > private long id;
> > ...
> >
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > public long getId() {
> > return id;
> > }
> > ...
> > }
> >
> > The test asserts that this is a valid mapping. Granted that the spec
is
> > very unclear here, so I might be missing something. The pertinent spec
> > section here states:
>
> For what its worth, I think the mapping is not valid (according to my
interpretation of the spec).
> @Access(AccessType.FIELD) would need to be specified on the field to
take effect. Whether this mapping
> is valid in a sense that is ignores @Access(AccessType.FIELD) is a
different question.
>
> However, referring to your test, afaics the test and class in question
(Course3) uses
> @org.hibernate.annotations.AccessType("field") which is a different
thing altogether. Here we are dealing
> with the now deprecated org.hibernate.annotations.AccessType annotation.
AFAIK, this annotation used
> to be placed together with other mapping annotations.
>
> So what do we want to discuss here really?
>
> --Hardy
>
>
>
>
>
>
>
3:21 p.m.
On 26 Jan 2014, at 20:16, Steve Ebersole <steve(a)hibernate.org> wrote:
Ok, but... its still a good spring board to discuss this topic which
is strangely unclear and murky in terms of what we do and do not support.
Sure. I am just saying, we are discussing a wrong test. When I was implementing the JPA
@Access rules, I never had the intentions to support
the mapping which started the this thread. In my interoperation of the JPA spec it is
wrong. It should either thrown an exception (in fact I thought there
used to be some checks which would actually do that) or if anything just ignored the
annotation.
—Hardy
3:27 p.m.
Well we are in the position we are in already from one person making this
determination ;)
So that is the situation I am trying to avoid. As this thread is showing,
we all have different readings/interpretations of the same spec passages.
It is good to come to a consensus.
On Wed, Mar 26, 2014 at 2:21 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 26 Jan 2014, at 20:16, Steve Ebersole <steve(a)hibernate.org> wrote:
> Ok, but... its still a good spring board to discuss this topic which is
strangely unclear and murky in terms of what we do and do not support.
Sure. I am just saying, we are discussing a wrong test. When I was
implementing the JPA @Access rules, I never had the intentions to support
the mapping which started the this thread. In my interoperation of the JPA
spec it is wrong. It should either thrown an exception (in fact I thought
there
used to be some checks which would actually do that) or if anything just
ignored the annotation.
--Hardy
3:32 p.m.
I was under the assumption that the test was as I wrote it but Hardy proved my assumption
wrong here and I mixed @Access and @AccessType.
On 26 Mar 2014, at 20:14, Steve Ebersole <steve(a)hibernate.org> wrote:
So the spec does specifically say "It is not permitted to
specify a field as Access(PROPERTY) or a property as Access(FIELD)". I understanding
making usability choices when the spec is unclear. Do you think there is non-clarity in
that quote though?
Even if you say making usability choices when the spec is very clear, but
"wrong"... again I can live with that. But we need to be clear about that.
On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
My take on the spec as always been that I'd rather follow the intent,
the common sense above the letter. Likewise, I favored user experience
over spec strict adherence.
I did clash numerous time with the TCK in these targets but I still
prefer that over just doing something stupid but spec to the letter.
(this is general and not specific to that case).
Anyway so my take is pretty much as it was when I first implemented
@AccessType even if it steps over the spec at the margin.
BTW I'm also happy if we all decide I made a usability mistake that should be fixed.
Emmanuel
On Wed 2014-03-26 11:14, Steve Ebersole wrote:
> On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole <steve(a)hibernate.org>wrote:
>
> > It does violate the spec though, that's the problem:
> >
>
> Well it *could* be read to violate the spec. That's inherently the problem
> with specs that use unclear wording; they can be read and argued multiple
> ways.
>
>
>
> >
> > "... It is not permitted to specify a field as Access(PROPERTY) or a
> > property as Access(FIELD)..."
> >
> > which imo is exactly what this is doing (specifying a property as FIELD):
> >
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > public long getId() {
> > return id;
> > }
> >
> >
> >
> > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero
<sanne(a)hibernate.org>wrote:
> >
> >> I do of course agree that people should use a single strategy and
> >> stick to it, so I agree with your reading about what the "general
> >> expectation" is.
> >>
> >> But the original test represents a quite naturally looking example and
> >> it's hard to justify why that should be considered illegal; I'd
> >> probably be more inclined in making user's life easier than try to
> >> lecture them about how a proper mapping should look like.
> >>
> >> Ignoring any annotation leads to waste of time and debugging
> >> frustration, so rather than silently discarding a mis-positioned
> >> annotation I'd prefer a fail-fast approach; that said I think just
> >> applying them all - as long as there are no obvious conflicting
> >> annotations - would be even more user friendly and doesn't seem to
> >> violate any specific wording of the spec.
> >>
> >> Sanne
> >>
> >>
> >> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org> wrote:
> >> > Again from the spec (still discussing class-level Access(PROPERTY)) :
> >> "The
> >> > behavior is undefined if mapping annotations are placed on any
instance
> >> > variables defined by the class for which Access(FIELD) is not
> >> specified".
> >> >
> >> > Which to me implies that the expectation for switching access for a
> >> > particular field within such a class is to annotate the *field* with
> >> > Access(FIELD).
> >> >
> >> > Also the footnote to this sections seems very relevant:
> >> >
> >> > "[8] ... It is not permitted to specify a field as
Access(PROPERTY) or a
> >> > property as Access(FIELD)..."
> >> >
> >> >
> >> >
> >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
> >> emmanuel(a)hibernate.org>
> >> > wrote:
> >> >>
> >> >> My reading at the time and what I did find more intuitive is what
the
> >> >> test represents.
> >> >>
> >> >> Entity level @AccessType expresses where the annotations should
> >> >> be. Otherwise the position of @Id is used to find the access type
to
> >> >> consider annotation wise.
> >> >>
> >> >> If for a few attributes I wish to use the alternative property
access,
> >> I
> >> >> can add @AccessType next to the other annotations but expressing
that
> >> >> the actual property value access is based on the alternative
access.
> >> >> That way, all annotations are in the same place.
> >> >>
> >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> >> >> > As a user I would not expect the @Access annotation to be
treated as
> >> a
> >> >> > special case by the framework in terms of when an annotation
is
> >> >> > ignored, as for example that I can put this on either
properties or
> >> >> > fields, and it would not be ignored, while other annotations
could be
> >> >> > ignored depending on the position.
> >> >> >
> >> >> > Also I highly doubt that there is a practical use case to
"comment" a
> >> >> > mapping annotation by moving it to the wrong position (say I
move a
> >> >> > @GeneratedValue from a field to a property when using FIELD
access):
> >> >> > that would be extremely confusing to maintain.
> >> >> >
> >> >> > The spec's wording states "When Access(PROPERTY) is
applied to an
> >> >> > [...] mapping annotations **may** be placed on .."
> >> >> > I'd stress that it doesn' t say "must" but
"may", and also doesn't
> >> >> > seem to strictly ban the opposite.
> >> >> >
> >> >> > As a user if I put a mapping annotation anywhere I expect it
to be
> >> >> > respected, so I would expect the framework to work on the
union of
> >> the
> >> >> > possible positions, and probably even to throw an exception
on
> >> >> > conflicting options. The @Access property would then only be
used to
> >> >> > state which access strategy should be used (and a nice effect
is tha
> >> >> > the name becomes particularly self-explanatory too).
> >> >> >
> >> >> > Also there are many types of possible contradictions in the
mapping
> >> >> > options:
> >> >> >
> >> >> > public class Course {
> >> >> > @Id @GeneratedValue(strategy=TABLE)
> >> >> > private long id;
> >> >> > ...
> >> >> >
> >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> >> > public long getId() {
> >> >> > return id;
> >> >> > }
> >> >> >
> >> >> > Or you could have a stronger conflict which isn't
solvable via
> >> >> > AccesType "rules" either:
> >> >> >
> >> >> > public class Course {
> >> >> > @Id @GeneratedValue(strategy=TABLE)
> >> >> > @Access(AccessType.FIELD)
> >> >> > private long id;
> >> >> > ...
> >> >> >
> >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> >> >> > @Access(AccessType.PROPERTY)
> >> >> > public long getId() {
> >> >> > return id;
> >> >> > }
> >> >> >
> >> >> > This last example is the reason why I think you should
always
> >> >> > consistently look at both to collect mapping options, and
possibly
> >> >> > throw runtime exceptions.
> >> >> >
> >> >> > Sanne
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org> wrote:
> >> >> > > >From the test
> >> >> > >
> >> >> > >
> >>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> >> >> > > we have the following:
> >> >> > >
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > The test asserts that this is a valid mapping. Granted
that the
> >> spec
> >> >> > > is
> >> >> > > very unclear here, so I might be missing something. The
pertinent
> >> >> > > spec
> >> >> > > section here states:
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > *<quote>When Access(PROPERTY) is applied to an
entity class, mapped
> >> >> > > superclass, or embeddableclass, mapping annotations may
be placed
> >> on
> >> >> > > the
> >> >> > > properties of that class, and the persistenceprovider
runtime
> >> accesses
> >> >> > > persistent state via the properties defined by that
class. All
> >> >> > > proper-ties
> >> >> > > that are not annotated with the Transient annotation
are
> >> persistent.
> >> >> > > WhenAccess(PROPERTY) is applied to such a class, it is
possible to
> >> >> > > selectively designate indi-vidual attributes within the
class for
> >> >> > > instance
> >> >> > > variable access. To specify a persistent
instancevariable for
> >> access
> >> >> > > by the
> >> >> > > persistence provider runtime, that instance variable
must be
> >> >> > > desig-nated
> >> >> > > Access(FIELD).</quote>*
> >> >> > >
> >> >> > >
> >> >> > > I can see a few different ways to read that:
> >> >> > >
> >> >> > > 1) @Access can be placed on the attribute to define both
where to
> >> look
> >> >> > > for
> >> >> > > mapping annotations and the runtime access strategy for
a given
> >> >> > > attribute.
> >> >> > > Here, we'd do:
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > 2) @Access can be placed on the attribute to define the
runtime
> >> access
> >> >> > > strategy for a given attribute, but the class/hierarchy
AccessType
> >> >> > > controls
> >> >> > > where to look for mapping annotations. This would lead
to:
> >> >> > >
> >> >> > > @Entity
> >> >> > > @Access(AccessType.PROPERTY)
> >> >> > > public class Course3 {
> >> >> > > @Access(AccessType.FIELD)
> >> >> > > private long id;
> >> >> > > ...
> >> >> > >
> >> >> > > @Id
> >> >> > > @GeneratedValue
> >> >> > > public long getId() {
> >> >> > > return id;
> >> >> > > }
> >> >> > > ...
> >> >> > > }
> >> >> > >
> >> >> > > The test seems to illustrate that our legacy code made
yet a 3rd
> >> >> > > reading of
> >> >> > > this passage such that @Access is still considered a
"mapping
> >> >> > > annotation"
> >> >> > > even though that seems to directly contradict "To
specify a
> >> persistent
> >> >> > > instance
> >> >> > > variable for access by the persistence provider runtime,
that
> >> instance
> >> >> > > variable must be desig-
> >> >> > > nated Access(FIELD)."
> >> >> > >
> >> >> > >
> >> >> > > Is there some other passage I am missing that bears on
what to do
> >> >> > > here?
> >> >> > > How do y'all feel about that passage and its
implications on this
> >> >> > > test
> >> >> > > mapping?
> >> >> > > _______________________________________________
> >> >> > > hibernate-dev mailing list
> >> >> > > hibernate-dev(a)lists.jboss.org
> >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> > _______________________________________________
> >> >> > hibernate-dev mailing list
> >> >> > hibernate-dev(a)lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >>
> >
> >
3:36 p.m.
On 26 Jan 2014, at 15:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
But the original test represents a quite naturally looking example
and
it's hard to justify why that should be considered illegal;
Because it is against the rules for the placement of @Access.
At least in my interpretation of the spec.
Ignoring any annotation leads to waste of time and debugging
frustration, so rather than silently discarding a mis-positioned
annotation I'd prefer a fail-fast approach;
True. There are several bug reports due to the fact that we ignore mapping information.
However, we never have taken all annotations into consideration. The approach has always
been to first determine where to look for annotations (per default based on the placement
of
the @Id annotation) and then only consider annotations placed according to the discovered
strategy.
I would assume there were two reasons for ignoring “wrongly” placed annotations:
- annotation processing time and the attempt to avoid accessing all fields and getters via
reflection
- a considerable extra effort in coding to do proper processing and error handling
Personally I could imagine an option where we determine an default annotation placement
and
throw an exception if any mapping annotation is wrongly placed. If the option is disabled
we ignore (maybe log) the annotation.
that said I think just
applying them all - as long as there are no obvious conflicting
annotations - would be even more user friendly and doesn't seem to
violate any specific wording of the spec.
-1
—Hardy
4:07 p.m.
I also renamed @AccessType (out custom one) to be @AttributeAccessor to
better avoid confusion with the JPA names.
On Wed, Mar 26, 2014 at 2:32 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
I was under the assumption that the test was as I wrote it but Hardy
proved my assumption wrong here and I mixed @Access and @AccessType.
On 26 Mar 2014, at 20:14, Steve Ebersole <steve(a)hibernate.org> wrote:
So the spec does specifically say "It is not permitted to specify a field
as Access(PROPERTY) or a property as Access(FIELD)". I understanding
making usability choices when the spec is unclear. Do you think there is
non-clarity in that quote though?
Even if you say making usability choices when the spec is very clear, but
"wrong"... again I can live with that. But we need to be clear about that.
On Wed, Mar 26, 2014 at 11:21 AM, Emmanuel Bernard <emmanuel(a)hibernate.org
> wrote:
> My take on the spec as always been that I'd rather follow the intent,
> the common sense above the letter. Likewise, I favored user experience
> over spec strict adherence.
> I did clash numerous time with the TCK in these targets but I still
> prefer that over just doing something stupid but spec to the letter.
> (this is general and not specific to that case).
>
> Anyway so my take is pretty much as it was when I first implemented
> @AccessType even if it steps over the spec at the margin.
> BTW I'm also happy if we all decide I made a usability mistake that
> should be fixed.
>
> Emmanuel
>
> On Wed 2014-03-26 11:14, Steve Ebersole wrote:
> > On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole <steve(a)hibernate.org
> >wrote:
> >
> > > It does violate the spec though, that's the problem:
> > >
> >
> > Well it *could* be read to violate the spec. That's inherently the
> problem
> > with specs that use unclear wording; they can be read and argued
> multiple
> > ways.
> >
> >
> >
> > >
> > > "... It is not permitted to specify a field as Access(PROPERTY) or a
> > > property as Access(FIELD)..."
> > >
> > > which imo is exactly what this is doing (specifying a property as
> FIELD):
> > >
> > > @Id
> > > @GeneratedValue
> > > @Access(AccessType.FIELD)
> > > public long getId() {
> > > return id;
> > > }
> > >
> > >
> > >
> > > On Wed, Mar 26, 2014 at 9:56 AM, Sanne Grinovero <sanne(a)hibernate.org
> >wrote:
> > >
> > >> I do of course agree that people should use a single strategy and
> > >> stick to it, so I agree with your reading about what the "general
> > >> expectation" is.
> > >>
> > >> But the original test represents a quite naturally looking example
> and
> > >> it's hard to justify why that should be considered illegal;
I'd
> > >> probably be more inclined in making user's life easier than try to
> > >> lecture them about how a proper mapping should look like.
> > >>
> > >> Ignoring any annotation leads to waste of time and debugging
> > >> frustration, so rather than silently discarding a mis-positioned
> > >> annotation I'd prefer a fail-fast approach; that said I think just
> > >> applying them all - as long as there are no obvious conflicting
> > >> annotations - would be even more user friendly and doesn't seem to
> > >> violate any specific wording of the spec.
> > >>
> > >> Sanne
> > >>
> > >>
> > >> On 26 March 2014 13:57, Steve Ebersole <steve(a)hibernate.org>
wrote:
> > >> > Again from the spec (still discussing class-level
> Access(PROPERTY)) :
> > >> "The
> > >> > behavior is undefined if mapping annotations are placed on any
> instance
> > >> > variables defined by the class for which Access(FIELD) is not
> > >> specified".
> > >> >
> > >> > Which to me implies that the expectation for switching access for
a
> > >> > particular field within such a class is to annotate the *field*
> with
> > >> > Access(FIELD).
> > >> >
> > >> > Also the footnote to this sections seems very relevant:
> > >> >
> > >> > "[8] ... It is not permitted to specify a field as
> Access(PROPERTY) or a
> > >> > property as Access(FIELD)..."
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Mar 26, 2014 at 8:02 AM, Emmanuel Bernard <
> > >> emmanuel(a)hibernate.org>
> > >> > wrote:
> > >> >>
> > >> >> My reading at the time and what I did find more intuitive is
what
> the
> > >> >> test represents.
> > >> >>
> > >> >> Entity level @AccessType expresses where the annotations
should
> > >> >> be. Otherwise the position of @Id is used to find the access
type
> to
> > >> >> consider annotation wise.
> > >> >>
> > >> >> If for a few attributes I wish to use the alternative
property
> access,
> > >> I
> > >> >> can add @AccessType next to the other annotations but
expressing
> that
> > >> >> the actual property value access is based on the alternative
> access.
> > >> >> That way, all annotations are in the same place.
> > >> >>
> > >> >> On Wed 2014-03-26 11:12, Sanne Grinovero wrote:
> > >> >> > As a user I would not expect the @Access annotation to
be
> treated as
> > >> a
> > >> >> > special case by the framework in terms of when an
annotation is
> > >> >> > ignored, as for example that I can put this on either
> properties or
> > >> >> > fields, and it would not be ignored, while other
annotations
> could be
> > >> >> > ignored depending on the position.
> > >> >> >
> > >> >> > Also I highly doubt that there is a practical use case
to
> "comment" a
> > >> >> > mapping annotation by moving it to the wrong position
(say I
> move a
> > >> >> > @GeneratedValue from a field to a property when using
FIELD
> access):
> > >> >> > that would be extremely confusing to maintain.
> > >> >> >
> > >> >> > The spec's wording states "When Access(PROPERTY)
is applied to
> an
> > >> >> > [...] mapping annotations **may** be placed on .."
> > >> >> > I'd stress that it doesn' t say "must"
but "may", and also
> doesn't
> > >> >> > seem to strictly ban the opposite.
> > >> >> >
> > >> >> > As a user if I put a mapping annotation anywhere I expect
it to
> be
> > >> >> > respected, so I would expect the framework to work on the
union
> of
> > >> the
> > >> >> > possible positions, and probably even to throw an
exception on
> > >> >> > conflicting options. The @Access property would then only
be
> used to
> > >> >> > state which access strategy should be used (and a nice
effect
> is tha
> > >> >> > the name becomes particularly self-explanatory too).
> > >> >> >
> > >> >> > Also there are many types of possible contradictions in
the
> mapping
> > >> >> > options:
> > >> >> >
> > >> >> > public class Course {
> > >> >> > @Id @GeneratedValue(strategy=TABLE)
> > >> >> > private long id;
> > >> >> > ...
> > >> >> >
> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> > >> >> > public long getId() {
> > >> >> > return id;
> > >> >> > }
> > >> >> >
> > >> >> > Or you could have a stronger conflict which isn't
solvable via
> > >> >> > AccesType "rules" either:
> > >> >> >
> > >> >> > public class Course {
> > >> >> > @Id @GeneratedValue(strategy=TABLE)
> > >> >> > @Access(AccessType.FIELD)
> > >> >> > private long id;
> > >> >> > ...
> > >> >> >
> > >> >> > @Id @GeneratedValue(strategy=SEQUENCE)
> > >> >> > @Access(AccessType.PROPERTY)
> > >> >> > public long getId() {
> > >> >> > return id;
> > >> >> > }
> > >> >> >
> > >> >> > This last example is the reason why I think you should
always
> > >> >> > consistently look at both to collect mapping options,
and
> possibly
> > >> >> > throw runtime exceptions.
> > >> >> >
> > >> >> > Sanne
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > On 26 March 2014 04:13, Steve Ebersole
<steve(a)hibernate.org>
> wrote:
> > >> >> > > >From the test
> > >> >> > >
> > >> >> > >
> > >>
>
org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> > >> >> > > we have the following:
> > >> >> > >
> > >> >> > >
> > >> >> > > @Entity
> > >> >> > > @Access(AccessType.PROPERTY)
> > >> >> > > public class Course3 {
> > >> >> > > private long id;
> > >> >> > > ...
> > >> >> > >
> > >> >> > > @Id
> > >> >> > > @GeneratedValue
> > >> >> > > @Access(AccessType.FIELD)
> > >> >> > > public long getId() {
> > >> >> > > return id;
> > >> >> > > }
> > >> >> > > ...
> > >> >> > > }
> > >> >> > >
> > >> >> > > The test asserts that this is a valid mapping.
Granted that
> the
> > >> spec
> > >> >> > > is
> > >> >> > > very unclear here, so I might be missing something.
The
> pertinent
> > >> >> > > spec
> > >> >> > > section here states:
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > *<quote>When Access(PROPERTY) is applied to an
entity class,
> mapped
> > >> >> > > superclass, or embeddableclass, mapping annotations
may be
> placed
> > >> on
> > >> >> > > the
> > >> >> > > properties of that class, and the
persistenceprovider runtime
> > >> accesses
> > >> >> > > persistent state via the properties defined by that
class. All
> > >> >> > > proper-ties
> > >> >> > > that are not annotated with the Transient annotation
are
> > >> persistent.
> > >> >> > > WhenAccess(PROPERTY) is applied to such a class, it
is
> possible to
> > >> >> > > selectively designate indi-vidual attributes within
the class
> for
> > >> >> > > instance
> > >> >> > > variable access. To specify a persistent
instancevariable for
> > >> access
> > >> >> > > by the
> > >> >> > > persistence provider runtime, that instance variable
must be
> > >> >> > > desig-nated
> > >> >> > > Access(FIELD).</quote>*
> > >> >> > >
> > >> >> > >
> > >> >> > > I can see a few different ways to read that:
> > >> >> > >
> > >> >> > > 1) @Access can be placed on the attribute to define
both
> where to
> > >> look
> > >> >> > > for
> > >> >> > > mapping annotations and the runtime access strategy
for a
> given
> > >> >> > > attribute.
> > >> >> > > Here, we'd do:
> > >> >> > >
> > >> >> > > @Entity
> > >> >> > > @Access(AccessType.PROPERTY)
> > >> >> > > public class Course3 {
> > >> >> > > @Id
> > >> >> > > @GeneratedValue
> > >> >> > > @Access(AccessType.FIELD)
> > >> >> > > private long id;
> > >> >> > > ...
> > >> >> > >
> > >> >> > > public long getId() {
> > >> >> > > return id;
> > >> >> > > }
> > >> >> > > ...
> > >> >> > > }
> > >> >> > >
> > >> >> > > 2) @Access can be placed on the attribute to define
the
> runtime
> > >> access
> > >> >> > > strategy for a given attribute, but the
class/hierarchy
> AccessType
> > >> >> > > controls
> > >> >> > > where to look for mapping annotations. This would
lead to:
> > >> >> > >
> > >> >> > > @Entity
> > >> >> > > @Access(AccessType.PROPERTY)
> > >> >> > > public class Course3 {
> > >> >> > > @Access(AccessType.FIELD)
> > >> >> > > private long id;
> > >> >> > > ...
> > >> >> > >
> > >> >> > > @Id
> > >> >> > > @GeneratedValue
> > >> >> > > public long getId() {
> > >> >> > > return id;
> > >> >> > > }
> > >> >> > > ...
> > >> >> > > }
> > >> >> > >
> > >> >> > > The test seems to illustrate that our legacy code
made yet a
> 3rd
> > >> >> > > reading of
> > >> >> > > this passage such that @Access is still considered a
"mapping
> > >> >> > > annotation"
> > >> >> > > even though that seems to directly contradict
"To specify a
> > >> persistent
> > >> >> > > instance
> > >> >> > > variable for access by the persistence provider
runtime, that
> > >> instance
> > >> >> > > variable must be desig-
> > >> >> > > nated Access(FIELD)."
> > >> >> > >
> > >> >> > >
> > >> >> > > Is there some other passage I am missing that bears
on what
> to do
> > >> >> > > here?
> > >> >> > > How do y'all feel about that passage and its
implications on
> this
> > >> >> > > test
> > >> >> > > mapping?
> > >> >> > > _______________________________________________
> > >> >> > > hibernate-dev mailing list
> > >> >> > > hibernate-dev(a)lists.jboss.org
> > >> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >> > _______________________________________________
> > >> >> > hibernate-dev mailing list
> > >> >> > hibernate-dev(a)lists.jboss.org
> > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >
> > >> >
> > >>
> > >
> > >
>
4:09 p.m.
I really like the general approach you did in metamodel. In fact, even
though I heavily refactored most of that package, the way annotated members
are found is largely unchanged.
But specifically, take Sanne's example. Access(PROPERTY) for the class.
Then for one attribute they want field *access* (runtime). How would you
see that? Like I said initially, I think there are 2 potentially valid
ways to support this.
First,
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Id
@GeneratedValue
@Access(AccessType.FIELD)
private long id;
...
public long getId() {
return id;
}
...
}
This approach gives credence to the passage I have been quoting here: "It
is not permitted to specify a field as Access(PROPERTY) or a property as
Access(FIELD)".
Second,
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
private long id;
...
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
...
}
I prefer the first one.
On Wed, Mar 26, 2014 at 2:36 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 26 Jan 2014, at 15:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> But the original test represents a quite naturally looking example and
> it's hard to justify why that should be considered illegal;
Because it is against the rules for the placement of @Access.
At least in my interpretation of the spec.
> Ignoring any annotation leads to waste of time and debugging
> frustration, so rather than silently discarding a mis-positioned
> annotation I'd prefer a fail-fast approach;
True. There are several bug reports due to the fact that we ignore
mapping information.
However, we never have taken all annotations into consideration. The
approach has always
been to first determine where to look for annotations (per default based
on the placement of
the @Id annotation) and then only consider annotations placed according to
the discovered strategy.
I would assume there were two reasons for ignoring "wrongly" placed
annotations:
- annotation processing time and the attempt to avoid accessing all fields
and getters via reflection
- a considerable extra effort in coding to do proper processing and error
handling
Personally I could imagine an option where we determine an default
annotation placement and
throw an exception if any mapping annotation is wrongly placed. If the
option is disabled
we ignore (maybe log) the annotation.
> that said I think just
> applying them all - as long as there are no obvious conflicting
> annotations - would be even more user friendly and doesn't seem to
> violate any specific wording of the spec.
-1
--Hardy
4:26 p.m.
On 26 Jan 2014, at 21:09, Steve Ebersole <steve(a)hibernate.org> wrote:
I really like the general approach you did in metamodel. In fact,
even though I heavily refactored most of that package, the way annotated members are found
is largely unchanged.
But specifically, take Sanne's example. Access(PROPERTY) for the class. Then for
one attribute they want field *access* (runtime). How would you see that? Like I said
initially, I think there are 2 potentially valid ways to support this.
First,
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
@Id
@GeneratedValue
@Access(AccessType.FIELD)
private long id;
...
public long getId() {
return id;
}
...
}
This approach gives credence to the passage I have been quoting here: "It is not
permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD)".
Second,
@Entity
@Access(AccessType.PROPERTY)
public class Course3 {
private long id;
...
@Id
@GeneratedValue
@Access(AccessType.FIELD)
public long getId() {
return id;
}
...
}
I prefer the first one.
I prefer #1 as well
4:39 p.m.
One thing I suggested on IRC (because of the awesomely centralized job you
did here) was to possibly extract this into a strategy. We could have a
legacy one that follows what Emmanuel decided initially, and then another
that does what we all agree here as the correct thing moving forward.
On Wed, Mar 26, 2014 at 3:26 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 26 Jan 2014, at 21:09, Steve Ebersole <steve(a)hibernate.org> wrote:
> I really like the general approach you did in metamodel. In fact, even
though I heavily refactored most of that package, the way annotated members
are found is largely unchanged.
>
> But specifically, take Sanne's example. Access(PROPERTY) for the class.
Then for one attribute they want field *access* (runtime). How would you
see that? Like I said initially, I think there are 2 potentially valid
ways to support this.
>
> First,
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> private long id;
> ...
>
> public long getId() {
> return id;
> }
> ...
> }
>
> This approach gives credence to the passage I have been quoting here:
"It is not permitted to specify a field as Access(PROPERTY) or a property
as Access(FIELD)".
>
>
> Second,
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
> private long id;
> ...
>
> @Id
> @GeneratedValue
> @Access(AccessType.FIELD)
> public long getId() {
> return id;
> }
> ...
> }
>
> I prefer the first one.
I prefer #1 as well
5:29 p.m.
BTW, here is the topical guide I have started for this:
https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab...
On Wed, Mar 26, 2014 at 3:39 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
One thing I suggested on IRC (because of the awesomely centralized
job you
did here) was to possibly extract this into a strategy. We could have a
legacy one that follows what Emmanuel decided initially, and then another
that does what we all agree here as the correct thing moving forward.
On Wed, Mar 26, 2014 at 3:26 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
>
> On 26 Jan 2014, at 21:09, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> > I really like the general approach you did in metamodel. In fact, even
> though I heavily refactored most of that package, the way annotated members
> are found is largely unchanged.
> >
> > But specifically, take Sanne's example. Access(PROPERTY) for the
> class. Then for one attribute they want field *access* (runtime). How
> would you see that? Like I said initially, I think there are 2 potentially
> valid ways to support this.
> >
> > First,
> >
> > @Entity
> > @Access(AccessType.PROPERTY)
> > public class Course3 {
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > private long id;
> > ...
> >
> > public long getId() {
> > return id;
> > }
> > ...
> > }
> >
> > This approach gives credence to the passage I have been quoting here:
> "It is not permitted to specify a field as Access(PROPERTY) or a property
> as Access(FIELD)".
> >
> >
> > Second,
> >
> > @Entity
> > @Access(AccessType.PROPERTY)
> > public class Course3 {
> > private long id;
> > ...
> >
> > @Id
> > @GeneratedValue
> > @Access(AccessType.FIELD)
> > public long getId() {
> > return id;
> > }
> > ...
> > }
> >
> > I prefer the first one.
>
> I prefer #1 as well
6:36 a.m.
On 26 Jan 2014, at 22:29, Steve Ebersole <steve(a)hibernate.org> wrote:
BTW, here is the topical guide I have started for this:
https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab...
Very good start. Missing the more complicated cases with explicit class leave specified
access type and overrides on the attributes, but it for sure helps understanding the whole
concepts.
Really like the idea of topical guides more and more. I think they are not only valuable
for users of ORM, but also for us. They document assumptions/behaviour which help
understanding
decisions made in the code.
—Hardy
7:53 a.m.
On 26 March 2014 20:20, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 26 Jan 2014, at 21:07, Steve Ebersole <steve(a)hibernate.org> wrote:
> I also renamed @AccessType (out custom one) to be @AttributeAccessor to
> better avoid confusion with the JPA names.
+1 Definitely the better choice
I don't argue with that, but the context of my example was "assuming
my team has the convention of always putting mappings on properties",
so in such a case I'd want to use the second.
I really have no strong feeling against how you all think it should be
or any spec wording, my only concern is what happens when someone does
have a different interpretation or opinion. AFAIK today these are
ignored: would be nice to eventually be able to strictly validate (for
whatever decison you might take).
I think that's important to be taken into consideration while you work
on how Jandex reads things: to be able to provide strict validation,
you will need to be able to read annotations from both positions.
Sanne
9:51 a.m.
On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
I don't argue with that, but the context of my example was "assuming
my team has the convention of always putting mappings on properties",
so in such a case I'd want to use the second.
Like I said, I could really live with either interpretation. The sole
reason I lean towards #1 is the idea of consistency. If you start allowing
@Access(FIELD) on getters all of a sudden @Access(FIELD) has a different
semantic depending on where you find it (class versus attribute).
As I am writing the topical guide, I am realizing there are really 3
questions involved here:
1) How do I determine what is (versus is not) a "persistent attribute"?
2) Where do I look for mapping annotations for each persistent attribute?
3) How do I access persistent attribute values at runtime?
This is really where we all (and not just us...) have varying opinions.
Like you think (1) and (2) should be handled distinctly, whereas the rest
of us (iiuc) think that (1) and (2) should be determined via the same logic.
Further, you see the (1)/(2) combo as distinct from (3). To you
@Access(FIELD) on the getter is fine because of this; there @Access(FIELD)
is merely identifying the style of runtime access.
Not saying either is right or wrong. I just think it helps to better
understand where/why we all agree/disagree. Which ultimately gives us
better understanding in these discussions.
I really have no strong feeling against how you all think it should
be
or any spec wording, my only concern is what happens when someone does
have a different interpretation or opinion. AFAIK today these are
ignored: would be nice to eventually be able to strictly validate (for
whatever decison you might take).
I think that's important to be taken into consideration while you work
on how Jandex reads things: to be able to provide strict validation,
you will need to be able to read annotations from both positions.
For sure. This is one of the things metamodel is striving to do better
than before in regards to recognizing and warning about misplaced
annotations that will be ignored.
9:56 a.m.
On Thu, Mar 27, 2014 at 5:36 AM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 26 Jan 2014, at 22:29, Steve Ebersole <steve(a)hibernate.org> wrote:
> BTW, here is the topical guide I have started for this:
https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab...
Very good start. Missing the more complicated cases with explicit class
leave specified access type and overrides on the attributes, but it for
sure helps understanding the whole concepts.
Hence the phrase "started" ;)
Really like the idea of topical guides more and more. I think they
are not
only valuable for users of ORM, but also for us. They document
assumptions/behaviour which help understanding
decisions made in the code.
Definitely. Good documentation/guides are for more than users. They help
us as developers understand the expectations and intentions. They act as
"organizational memory". And they help us write and debug tests wrt those
expectations and intentions.
10:50 a.m.
Here is how I phrase this atm in the topical guide:
[NOTE]
====
It is important to understand that generally speaking the phrase "access
type" refers to a number of concepts:
* Determining which fields/methods constitute a persistent attribute.
* Indicating where to look for mapping annotations.
* How the attribute (its value) is accessed at runtime
For the most part, Hibernate treats all 3 as being the same. There are
some caveats here, which we will cover
as we go along.
====
On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
>
> I don't argue with that, but the context of my example was "assuming
> my team has the convention of always putting mappings on properties",
> so in such a case I'd want to use the second.
>
Like I said, I could really live with either interpretation. The sole
reason I lean towards #1 is the idea of consistency. If you start allowing
@Access(FIELD) on getters all of a sudden @Access(FIELD) has a different
semantic depending on where you find it (class versus attribute).
As I am writing the topical guide, I am realizing there are really 3
questions involved here:
1) How do I determine what is (versus is not) a "persistent attribute"?
2) Where do I look for mapping annotations for each persistent attribute?
3) How do I access persistent attribute values at runtime?
This is really where we all (and not just us...) have varying opinions.
Like you think (1) and (2) should be handled distinctly, whereas the rest
of us (iiuc) think that (1) and (2) should be determined via the same logic.
Further, you see the (1)/(2) combo as distinct from (3). To you
@Access(FIELD) on the getter is fine because of this; there @Access(FIELD)
is merely identifying the style of runtime access.
Not saying either is right or wrong. I just think it helps to better
understand where/why we all agree/disagree. Which ultimately gives us
better understanding in these discussions.
> I really have no strong feeling against how you all think it should be
> or any spec wording, my only concern is what happens when someone does
> have a different interpretation or opinion. AFAIK today these are
> ignored: would be nice to eventually be able to strictly validate (for
> whatever decison you might take).
>
> I think that's important to be taken into consideration while you work
> on how Jandex reads things: to be able to provide strict validation,
> you will need to be able to read annotations from both positions.
>
For sure. This is one of the things metamodel is striving to do better
than before in regards to recognizing and warning about misplaced
annotations that will be ignored.
2:36 p.m.
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).
== 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.
On Thu, Mar 27, 2014 at 9:50 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
Here is how I phrase this atm in the topical guide:
[NOTE]
====
It is important to understand that generally speaking the phrase "access
type" refers to a number of concepts:
* Determining which fields/methods constitute a persistent attribute.
* Indicating where to look for mapping annotations.
* How the attribute (its value) is accessed at runtime
For the most part, Hibernate treats all 3 as being the same. There are
some caveats here, which we will cover
as we go along.
====
On Thu, Mar 27, 2014 at 8:51 AM, Steve Ebersole <steve(a)hibernate.org>wrote:
>
>
>
> On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero <sanne(a)hibernate.org>wrote:
>>
>> I don't argue with that, but the context of my example was "assuming
>> my team has the convention of always putting mappings on properties",
>> so in such a case I'd want to use the second.
>>
>
> Like I said, I could really live with either interpretation. The sole
> reason I lean towards #1 is the idea of consistency. If you start allowing
> @Access(FIELD) on getters all of a sudden @Access(FIELD) has a different
> semantic depending on where you find it (class versus attribute).
>
> As I am writing the topical guide, I am realizing there are really 3
> questions involved here:
> 1) How do I determine what is (versus is not) a "persistent attribute"?
> 2) Where do I look for mapping annotations for each persistent attribute?
> 3) How do I access persistent attribute values at runtime?
>
> This is really where we all (and not just us...) have varying opinions.
> Like you think (1) and (2) should be handled distinctly, whereas the rest
> of us (iiuc) think that (1) and (2) should be determined via the same logic.
>
> Further, you see the (1)/(2) combo as distinct from (3). To you
> @Access(FIELD) on the getter is fine because of this; there @Access(FIELD)
> is merely identifying the style of runtime access.
>
> Not saying either is right or wrong. I just think it helps to better
> understand where/why we all agree/disagree. Which ultimately gives us
> better understanding in these discussions.
>
>
>
>> I really have no strong feeling against how you all think it should be
>> or any spec wording, my only concern is what happens when someone does
>> have a different interpretation or opinion. AFAIK today these are
>> ignored: would be nice to eventually be able to strictly validate (for
>> whatever decison you might take).
>>
>> I think that's important to be taken into consideration while you work
>> on how Jandex reads things: to be able to provide strict validation,
>> you will need to be able to read annotations from both positions.
>>
>
> For sure. This is one of the things metamodel is striving to do better
> than before in regards to recognizing and warning about misplaced
> annotations that will be ignored.
>
3:01 p.m.
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.
12:59 p.m.
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.
3:06 p.m.
On 29 Jan 2014, at 17:59, Steve Ebersole <steve(a)hibernate.org> wrote:
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.
That’s sounds like a good idea which would give us most flexibility. It might create a
fair bit of more work initially though.
—Hardy
10:51 a.m.
I have pushed the latest topical guide:
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/...
Thoughts? Comments?
The "Attribute-level" section is still undone, but I think the rest of the
text lays out the expectations in that case (especially the "Extensions"
sections) ...
On Sat, Mar 29, 2014 at 2:06 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 29 Jan 2014, at 17:59, Steve Ebersole <steve(a)hibernate.org> wrote:
> 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.
That's sounds like a good idea which would give us most flexibility. It
might create a fair bit of more work initially though.
--Hardy
10:20 p.m.
I have heard no more comments, so I will move forward with this as stated
earlier.
Additionally, I started working the a PoC for the idea of making this
resolution pluggable. Here is the initial stroke for the contract:
/**
* Contract responsible for resolving the members that identify the
persistent
* attributes for a given class descriptor representing a managed type.
*
* These members (field or method) would be where we look for mapping
annotations
* for the attribute.
*
* Additionally, whether the member is a field or method would tell us the
default
* runtime access strategy
*
* @author Steve Ebersole
*/
public interface PersistentAttributeMemberResolver {
/**
* Given the ManagedType Java type descriptor and the implicit AccessType
* to use, resolve the members that indicate persistent attributes.
*
* @param managedTypeDescriptor The ManagedType Java type descriptor
* @param implicitAccessType The implicit AccessType for the resolution
*
* @return The list of "backing members"
*/
public List<MemberDescriptor> resolveMembers(
JavaTypeDescriptor managedTypeDescriptor,
AccessType implicitAccessType);
}
On Sun, Mar 30, 2014 at 9:51 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
I have pushed the latest topical guide:
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/...
Thoughts? Comments?
The "Attribute-level" section is still undone, but I think the rest of the
text lays out the expectations in that case (especially the "Extensions"
sections) ...
On Sat, Mar 29, 2014 at 2:06 PM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
>
> On 29 Jan 2014, at 17:59, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> > 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.
>
> That's sounds like a good idea which would give us most flexibility. It
> might create a fair bit of more work initially though.
>
> --Hardy
>
>
>
7:34 a.m.
On 2 Jan 2014, at 04:20, Steve Ebersole <steve(a)hibernate.org> wrote:
I have heard no more comments, so I will move forward with this as
stated earlier.
Sorry for the late reply. I had a read through and what you describe is what I would
expect (in fact I hope
I basically implemented it this way on the metamodel branch).
There is a typo in example 4:
@Entity
@Access(PROPERTY)
public class PublishedDocument extends Document
Should be @Access(FIELD)
Additionally, I started working the a PoC for the idea of making this
resolution pluggable. Here is the initial stroke for the contract:
/**
* Contract responsible for resolving the members that identify the persistent
* attributes for a given class descriptor representing a managed type.
*
* These members (field or method) would be where we look for mapping annotations
* for the attribute.
*
* Additionally, whether the member is a field or method would tell us the default
* runtime access strategy
*
* @author Steve Ebersole
*/
public interface PersistentAttributeMemberResolver {
/**
* Given the ManagedType Java type descriptor and the implicit AccessType
* to use, resolve the members that indicate persistent attributes.
*
* @param managedTypeDescriptor The ManagedType Java type descriptor
* @param implicitAccessType The implicit AccessType for the resolution
*
* @return The list of "backing members"
*/
public List<MemberDescriptor> resolveMembers(
JavaTypeDescriptor managedTypeDescriptor,
AccessType implicitAccessType);
}
Where MemberDescriptor and JavaTypeDescriptor are the descriptors from the new reflite
layer, right?
This should work.
—Hardy
1:32 p.m.
To wrap up for now... I went ahead an implemented the strategies we
discussed here. They are represented as:
1) org.hibernate.metamodel.spi.StandardPersistentAttributeMemberResolver
2) org.hibernate.metamodel.spi.LenientPersistentAttributeMemberResolver
StandardPersistentAttributeMemberResolver implements the JPA spec
guidelines as closely as possible.
LenientPersistentAttributeMemberResolver tries to be more lenient in the
way Sanne mentioned above. They will be pushed to master shortly if y'all
wanted to take a look.
Yes, MemberDescriptor and JavaTypeDescriptor are the reflite contracts
On Wed, Apr 2, 2014 at 6:34 AM, Hardy Ferentschik <hardy(a)hibernate.org>wrote:
On 2 Jan 2014, at 04:20, Steve Ebersole <steve(a)hibernate.org> wrote:
> I have heard no more comments, so I will move forward with this as
stated earlier.
Sorry for the late reply. I had a read through and what you describe is
what I would expect (in fact I hope
I basically implemented it this way on the metamodel branch).
There is a typo in example 4:
@Entity
@Access(PROPERTY)
public class PublishedDocument extends Document
Should be @Access(FIELD)
> Additionally, I started working the a PoC for the idea of making this
resolution pluggable. Here is the initial stroke for the contract:
>
>
> /**
> * Contract responsible for resolving the members that identify the
persistent
> * attributes for a given class descriptor representing a managed type.
> *
> * These members (field or method) would be where we look for mapping
annotations
> * for the attribute.
> *
> * Additionally, whether the member is a field or method would tell us
the default
> * runtime access strategy
> *
> * @author Steve Ebersole
> */
> public interface PersistentAttributeMemberResolver {
> /**
> * Given the ManagedType Java type descriptor and the implicit
AccessType
> * to use, resolve the members that indicate persistent attributes.
> *
> * @param managedTypeDescriptor The ManagedType Java type
descriptor
> * @param implicitAccessType The implicit AccessType for the
resolution
> *
> * @return The list of "backing members"
> */
> public List<MemberDescriptor> resolveMembers(
> JavaTypeDescriptor managedTypeDescriptor,
> AccessType implicitAccessType);
> }
Where MemberDescriptor and JavaTypeDescriptor are the descriptors from the
new reflite layer, right?
This should work.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3675
days inactive
3682
days old
40 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero -
Steve Ebersole