What's the rational for supporting the following?
@Entity
class Product {
...
}
@Entity
class Order {
...
}
@Entity
@IdClass(...)
class OrderLine {
@Id
private Order order;
@Id
private Product product;
}
Specifically, the declaration of the OrderLine primary key. Why
I was looking into some failures on master in regards to XML overrides for
JPA annotations in relation to our friend Access/AccessType. Which got me
to thinking...
How does the "mixin" code handle defining the target for the
AnnotationInstances it creates?
Seems to me this code would have really
On 26 March 2014 20:18, Hardy Ferentschik wrote:
>
> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote:
>
>> The classes in the ORM module are extremely widely used by our primary
>> target:
>>
>> - FullTextQuery
>> - Search
>> - FullTextSession
>>
>> and two more lesser ones, but I think the 3 ab
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.
On 26 Jan 2014, at 20:52, Sanne Grinovero wrote:
> The classes in the ORM module are extremely widely used by our primary target:
>
> - FullTextQuery
> - Search
> - FullTextSession
>
> and two more lesser ones, but I think the 3 above are probably "THE
> API”.
That was my thinking as well.
>
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
It's a though choice.
The classes in the ORM module are extremely widely used by our primary target:
- FullTextQuery
- Search
- FullTextSession
and two more lesser ones, but I think the 3 above are probably "THE
API". To move these out of the way we'd at least need to postpone the
OSGi work for
On 26 Jan 2014, at 13:55, Emmanuel Bernard wrote:
> I don't have a full grasp of the consequences, I'll need to think about
> it.
:-) There might be a couple of other package changes which would make sense
(unrelated to the
split package problem). I guess now is the time to discuss and apply
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
I don't have a full grasp of the consequences, I'll need to think about
it.
Here are a few comments in the mean time.
SearchFactory is not a SPI, it is used by application developers.
For scalability reasons, I would be tempted to move the orm module
classes out of the root package. But that is def
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
34 matches
Mail list logo
