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 i
On 2 Jan 2014, at 04:20, Steve Ebersole 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 metamode
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
per
I have pushed the latest topical guide:
https://github.com/hibernate/hibernate-orm/blob/master/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc
Thoughts? Comments?
The "Attribute-level" section is still undone, but I think the rest of the
text lays out the expectations in that
On 29 Jan 2014, at 17:59, Steve Ebersole 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
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
On 27 Jan 2014, at 19:36, Steve Ebersole 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
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 t
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.
On Thu, Mar 27, 2014 at 5:36 AM, Hardy Ferentschik wrote:
>
> On 26 Jan 2014, at 22:29, Steve Ebersole wrote:
>
> > BTW, here is the topical guide I have started for this:
> https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/to
On Thu, Mar 27, 2014 at 6:53 AM, Sanne Grinovero 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 in
On 26 March 2014 20:20, Hardy Ferentschik wrote:
>
> On 26 Jan 2014, at 21:07, Steve Ebersole 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 con
On 26 Jan 2014, at 22:29, Steve Ebersole wrote:
> BTW, here is the topical guide I have started for this:
> https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc
Very good start. Missing the m
BTW, here is the topical guide I have started for this:
https://github.com/hibernate/hibernate-orm/blob/f7b779ec60281408da80590ab2b0fdb5b98accf5/documentation/src/main/asciidoc/topical/accesstype/AccessType.adoc
On Wed, Mar 26, 2014 at 3:39 PM, Steve Ebersole wrote:
> One thing I suggested on
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 We
On 26 Jan 2014, at 21:09, Steve Ebersole 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(PROPERT
On 26 Jan 2014, at 21:07, Steve Ebersole wrote:
> I also renamed @AccessType (out custom one) to be @AttributeAccessor to
> better avoid confusion with the JPA names.
+1 Definitely the better choice
___
hibernate-dev mailing list
hibernate-dev@lists.
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 *acce
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 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
On 26 Jan 2014, at 15:56, Sanne Grinovero 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.
> Ig
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 wrote:
> So the spec does specifically say "It is not permitted to specify a field as
> Access(PROPERTY) or a prope
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
On 26 Jan 2014, at 20:16, Steve Ebersole 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 ru
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 wrote:
> Hi,
>
> you are right, the current code used @Access(AccessType.FIELD) -
> https://github.com
Hi,
you are right, the current code used @Access(AccessType.FIELD) -
https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/src/test/java/org/hibernate/test/annotations/access/jpa/Course3.java
However, this is wrong. I actually looked first in my local checkout which is a
bit out
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
On 26 Jan 2014, at 05:13, Steve Ebersole wrote:
>> From the test
> org.hibernate.test.annotations.access.jpa.AccessMappingTest#testExplicitPropertyAccessAnnotationsWithHibernateStyleOverride
> we have the following:
>
>
> @Entity
> @Access(AccessType.PROPERTY)
> public class Course3 {
>pri
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(F
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 wrote:
>
> On 26 Jan 2014, at 05:13, Steve Ebersole wrote:
>
> >> From the test
> >
> org.hibernate.test.annotations.access.jp
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 wrote:
> On 26 March 2014 18:37, Steve Ebersole wrote:
> >
On 26 March 2014 18:37, Steve Ebersole 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 ext
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 d
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 l
On Wed, Mar 26, 2014 at 10:12 AM, Steve Ebersole 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 permit
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 l
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 mo
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
particula
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 sen
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 alternati
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 p
>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(Acces
41 matches
Mail list logo
